Below are the main problems I ran into. Has anyone else run into these
issues? Did you come to the same conclusion?
Yes.
"build styles" are not appropriate for defining the
functionality/imports/exports of a product!
A product may have several *versions* (a debug or a release or
arbitrarily more) which may differ in their functionality and in
exporting/importing interfaces/libraries. This also may require a
different set of source files and resources, and a different set of
frameworks to link against.
For instance, the debug version of an application may include a "debug
menu". And the debug version of a certain framework may include source
files for checking the heap, showing the stack backtrace or provide for
certain other debugging functions. In the release version the special
debug functions shall not be available.
These "versions" are a completely different concept than that of "build
styles"!
Notice, each "version" may be compiled as deployment style, debug style
or whatever to build the product.
In XCode, you need to use different targets, when you have different
set of resources and files, or libraries to link against.
Any combination of versions to build a product is possible. But, most
likely, the final application - which should be a "release" version,
should be linked against the set of frameworks for the release version,
and the frameworks itself should be build as the "release" version,
which in turn links against the release versions of other frameworks,
etc.
I admit, that the idea behind "deployment style" and "debug style" is
not sufficient for solving these use cases elegantly in XCode (as
opposed to CW). And even more worse, XCode does not provide a
suffcient dependency analyses, which forces you to manually perform a
clean/build - if just re-linking would be sufficient. For large
projects, this might become a big (productivity) problem.
However XCode is flexible *enough* to manage (most of) it:
For instance, suppose you have a framework "core" and an application,
and a test application for your core framework (all in the same XCode
project). The core framework, comes in two versions: debug and final.
The two version of framework "core" have a different set of resources
and files and also export a different interface, thus these are two
different targets in XCode: core-debug and core.
It is assumed, that in the application code, conditional defines take
care of the different interfaces when importing the core framework,
respectively the core-debug framework. However, since the app links
against different frameworks, two targets are required: app-debug and
app - the sources are the same, though.
The same for the test app for testing the core framework:
test_core-debug and test_core, respectively.
So, your targets are:
app-debug
app
test_core-debug
test_core
core
core-debug
( "->" means linking against)
Use cases:
Debugging test_core-debug and framework core-debug:
test_core-debug (debug)
-> core-debug (debug)
Running test_core-debug linking against core-debug:
test_core-debug (deployment)
-> core-debug (deployment)
Debugging test_core and framework core:
test_core (debug)
-> core (debug)
Running test_core, linking against core:
test_core (deployment)
-> core (deployment)
Debugging the app linking against (validated and tested) framework
core-debug:
app-debug (debug)
-> core-debug (debug)
the final app:
app (deployment)
-> core (deployment)
Unless you remove the target "core" from the XCode project, this is
not possible, though:
Debugging the app, linking against (validated and tested) framework
"core-debug" in deployment build style:
app (debug)
-> core-debug (deployment)
nor
app (debug)
-> core (deployment)
I would be glad, if this becomes possible, in XCode 4.0 :-)
Managing a large project is still a challenge, though. :-)
Regards
Andreas
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/xcode-users/email@hidden
