Re: Porting projects from Windows
Re: Porting projects from Windows
- Subject: Re: Porting projects from Windows
- From: "Shawn Erickson" <email@hidden>
- Date: Wed, 10 Sep 2008 08:53:15 -0700
On Wed, Sep 10, 2008 at 8:36 AM, Shawn Erickson <email@hidden> wrote:
> On Tue, Sep 9, 2008 at 1:19 PM, Thomas Hauk <email@hidden> wrote:
>> I'm a Mac head since the 128k but I've been doing development on Windows for
>> several years now. Through about 4 different versions of Visual Studio, I've
>> come to appreciate its design philosophy of solutions and projects. It makes
>> managing large projects, with packages from external and internal sources,
>> quite a bit easier.
>>
>> Porting this project over to OS X has been a huge pain in the butt.
>
> That is because you think an Xcode project is like a VS project it
> isn't... An Xcode project is much more like an solution environment
> and targets in an Xcode project are more like projects in VS.
Clicked send instead of save by mistake...
Xcode has a very good build setting system that is hierarchical and
supports things like xcconfig files at many of the levels in the
hierarchy. As a result it is easy to maintain consistent settings
across all targets by having build settings at the project level and
overriding only those that are needed at the target level.
Additionally if you mix in the use of xcconfig files you can trivially
share common build settings across disjoint projects.
For example I work on a handful of cross-platform applications built
on a large shared code base packaged in libraries. By using xcconfig
files the 8 or so projects (further multiplied by multiple branches
for each) each with 3 to 10 targets all shared the same exact
configuration information (SDK, gcc flags, etc.) and only a small
handful of build settings are specified per target and often none at
the project level. As a result I can change the common build settings
in one place while on the Windows side they often have to hit up 20+
projects (not counting branches) to do something similar ...of course
ways exist to deal with this but...
Also learn to leverage script phases, copy phases, etc. that targets allow for.
The first rule of working with Xcode or developing for Mac is stop
trying to make it work like you are used to with Windows/VS (or other
platform). You will just fight with the tools, etc. ... instead take
some time to learn how things work and the thinking behind them and
then begin to work. The tools and framework on Mac OS X are rather
good, IMHO some of the best in the industry (long history of Mac,
Windows, Java, etc. development).
In other words take a day to fully read the Xcode 3 documentation (you
can find online or under the Help menu when you run Xcode). Google
will help you find pieces of information but the Xcode docs will help
paint the full picture.
Finally don't go crazy creating static libraries for every sub
component of a larger library of code (I see this often when working
on the Windows side of the fence) but instead consider making a single
static library that contains all of the sub components. Let the linker
pick out what you needs and while doing so reduce you project / target
/ build output work load.
-Shawn
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden