Re: Equivalent to xcconfig conditionals available?
Re: Equivalent to xcconfig conditionals available?
- Subject: Re: Equivalent to xcconfig conditionals available?
- From: "Mattias Arrelid" <email@hidden>
- Date: Sun, 26 Oct 2008 17:44:26 +0100
On Wed, Jun 25, 2008 at 18:57, Rush Manbert <email@hidden> wrote:
>
> On Jun 25, 2008, at 8:22 AM, Mattias Arrelid wrote:
>
>> On Wed, Jun 25, 2008 at 4:26 PM, Ken Thomases <email@hidden> wrote:
>>>
>>> On Jun 25, 2008, at 7:20 AM, Mattias Arrelid wrote:
>>>
>>>> The problem appears when we go to the next Xcode project (let's call
>>>> this the top level project, it produces an application bundle). Let's
>>>> pose that a target of this project will use one of the above mentioned
>>>> libraries. To do this, we add that library's Xcode project to our
>>>> Xcode project. In addition to this, we add the library target of that
>>>> Xcode project as a dependency of our target. Now, how can we, at this
>>>> level, specify a build setting that should be used in this target
>>>> _and_ all targets that we're depending on?
>>>
>>> I'm not sure that makes sense to me. If you're depending on the build
>>> product of another project's target, it should be whatever that target
>>> would
>>> produce even if it were built separately. If a target is to change what
>>> it
>>> produces based on what's using it, that just seems weird to me. Among
>>> other
>>> things, it introduces odd build dependency problems. (Is the product up
>>> to
>>> date? Well, it's newer than all of its source files, and its own build
>>> settings haven't changed, but hey, it's being used by another project
>>> which
>>> might be imposing its own build settings. So, we always have to rebuild
>>> it
>>> from scratch.)
>>>
>>> All that said, sub-targets are built using the build configuration name
>>> that's used for the referrer. So, if your referrers all use
>>> configuration
>>> names which are unique relative to each other, and your library target
>>> has
>>> corresponding configurations, each of which is based on a different
>>> .xcconfig, then you might be able to get what you're looking for. If
>>> that
>>> made sense.
>>
>> I know, this seems kind of messy :)
>>
>> Maybe I'm better off doing something like this:
>>
>> generic.xcconfig > {platform}.xcconfig > {configuration}.xcconfig >
>> {target}.xcconfig.
>>
>> The problem is, just like Chris mentioned earlier, that to include
>> {platform}.xcconfig I would have to base it on some other build
>> setting (which really isn't what I want to, nor can?, do). Seems I
>> might be stuck :/
>
> Could you achieve your goal by defining more build configurations that you
> use in all of your projects? Something like DebugPlatform1, DebugPlatform2,
> ReleasePlatform1, ReleasePlatform2, etc. Then your app bundle, when built
> with ReleasePlayformt configuration will pass that as the configuration to
> all dependent projects. It means more configurations to manage in each
> project, but you can use the Xcode config files to your advantage there.
Sorry for bumping this old thread, but we solved the problem by using
the [*]-syntax available in xcconfig files, like:
GCC_ENABLE_OBJC_GC[sdk=macosx*] = NO;
Thanks for all the suggestions, and sorry again for my late reply.
/ Mattias
_______________________________________________
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