Re: Conditional dependencies (and linked libraries) in a Xcode project?
Re: Conditional dependencies (and linked libraries) in a Xcode project?
- Subject: Re: Conditional dependencies (and linked libraries) in a Xcode project?
- From: "Mattias Arrelid" <email@hidden>
- Date: Mon, 12 May 2008 16:28:11 +0200
On Mon, May 12, 2008 at 3:39 PM, Ruslan Zasukhin
<email@hidden> wrote:
> On 5/12/08 3:38 PM, "Mattias Arrelid" <email@hidden> wrote:
>
>> Hi,
>>
>> We've got an Xcode project that consists of some source files that
>> links against a couple of static libraries (those libraries are
>> gathered under a separate Xcode umbrella project). This approach works
>> just fine.
>>
>> Now, we also have some parallel development of a new static library,
>> and this is where our "problems" begin to pop up; the maintainer of
>> that project wants to take _that_ Xcode project and include it in our
>> master project, just as with those other libraries. The problem is
>> that most others developers aren't very interested in those files
>> being implicitly compiled (since the main target of the main project
>> depends on each static library) each and every time they build the
>> main target from scratch.
>>
>> The only reasonable solution we've come up with so far is the "ifdef
>> and if macro guard"-approach; in each source file in the new static
>> library, there's an #ifdef combined with an #if in the top of the file
>> that checks whether a macro is set (and if, which value it has) or
>> not. Let's call this macro BUILD_WITH_NEW_STATIC_LIB. That macro is
>> set in a pre-compiled header (and it is 0 by default), and this works
>> just fine - the maintainer sets this to 1 locally in his checkout -
>> but it's far from elegant.
>>
>> Does anyone know of a better way of solving this?
>
> You can create in your new MASTER project few configurations, as
>
> NORMAL BUILD
> BUILD WITH STATIC LIBS
Configurations? Don't you mean targets? If so; I don't want to add
targets for each and every possible setting available in the project.
Just image that we add another in-house internal library that is
independent of the first one; then we would have four possible
configurations. Add another and we have six... and so on (should be !n
targets in total).
And neither do I want to add unique configurations; we do have
debug/release today, and they seem to work just fine. if we were to
take the above mentioned approach, we would have the same problem here
(!n configurations in total).
Or did I misinterpret you?
_______________________________________________
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