Re: Buildstyles Propogating to sub projects in XCode 1.5 ?
Re: Buildstyles Propogating to sub projects in XCode 1.5 ?
- Subject: Re: Buildstyles Propogating to sub projects in XCode 1.5 ?
- From: Andreas Grosam <email@hidden>
- Date: Fri, 22 Apr 2005 16:22:40 +0200
On 21.04.2005, at 21:02, Scott Tooker wrote:
Sorry, this is still the model in Xcode 2.0, but we are aware of the
issues the current model has and are investigating ways to improve it.
Scott
IMO, individual projects shall be orthogonal to each other. This
includes the build style settings as well, because products depend on
the build styles.
If i would require this behavior XCode currently exposes, i would
inlcude the sub project's targets into the main project.
But since it works that way, it is extremely difficult and tedious to
compose a complex project out of several sub-projects and manage all
settings which formerly were set in the build styles of each individual
project.
Since the build style settings override the target settings, an
individual sub-project may become corrupt. Furthermore, changes in the
settings of a project which were required to build correctly as a
sub-project, may then break it when building it standalone!
And there is always the danger that a reasonable change in the build
style setting of the master, has inadvertently and erroneous effects on
the sub-projects.
IMO, for larger software projects, using sub projects is a no go - it
is not managable!
I would suggest, that we have three choices which build style we want
to use for each sub-project:
1) use the build style with the same name as the master uses (most
reasonable, should be the default)
2) use xxx build style (e.g. in order to use a deployment version of
a framework for an app in "debug-state")
3) use the masters build style (for thrillseekers; this is current
behavior)
Andreas Grosam
On Apr 21, 2005, at 11:11 AM, Andrew Kimpton wrote:
Scott Tooker wrote:
In the current Xcode (1.5), the way that the build style is used is
intended behavior.
OK - I think I found a workaround by adding the library to the extra
linker flags of the bundle target and removing it from the deployment
build style. That way it's not propogated. It also means that the
library is linked in Development builds but nothing calls it and with
improved dead code stripping I guess it will 'fall out' anyways.
Your statement carries an implication that this style propogation
behvaiour has changed for XCode 2.0 ?
Thanks for the quick response.
Scott
Andrew 8-)
On Apr 21, 2005, at 10:26 AM, Andrew Kimpton wrote:
I have a project which builds a bundle, it in turn includes two
'sub projects' as dependant targets - each a static library of
common code.
It seems like the build style I pick for the 'top level' project
propogates to the sub projects not merely as a 'label' (ie use the
Deployment style from the libblah.xcode project) but as a concrete
set of build options.
This means that a -lxtra_lib flag I specify only in the deployment
build style (using Other Linker Flags) for the top level target is
being passed to the libtool command line of the two subprojects. I
don't want that extra library linked when I build the two
subprojects (aside from the library paths not being set correctly
to find it I don't think libtool allows for a string of .o files to
be combined with another .a archive to create a new .a archive ?)
Is this a known bug with a workaround ?
Andrew 8-)
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
email@hidden
This email sent to email@hidden
_______________________________________________
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
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
email@hidden
This email sent to email@hidden
_______________________________________________
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