Re: using a build style (was: wchar link problems building for jaguar)
Re: using a build style (was: wchar link problems building for jaguar)
- Subject: Re: using a build style (was: wchar link problems building for jaguar)
- From: Scott Tooker <email@hidden>
- Date: Wed, 5 Nov 2003 16:52:32 -0800
You want to use $(value).
So in the header search paths entry for the build style you'd have:
$(value) <the set of paths to add to all targets>
(Note: $(value) can go anywhere in the build setting, it just
represents the setting of the underlying target).
Scott
On Nov 5, 2003, at 4:24 PM, Rob Barris wrote:
>
> If I put the paths below into the header search paths entry for the
> build style, then I see a line drawn through that setting in the Get
> Info pane for each of the subordinate targets - and they don't build
> because the specific paths added by each target are no longer in
> effect (an inference based on the UI feedback and on the error
> messages that spew out).
>
> I need to be able to make a union between the paths provided at the
> top level in the build style and the paths provided in each target's
> unique setup, so that each target is using the common paths in
> combination with its uniquely set paths. Is there a way to do that ?
>
> thanks for the help, Rob
>
>
> On Nov 5, 2003, at 11:16 AM, Scott Tooker wrote:
>
>> Try using a build style.
>>
>> Scott
>>
>> On Nov 5, 2003, at 10:10 AM, Rob Barris wrote:
>>
>>>> From: Brent Marykuca <email@hidden>
>>>> Subject: Re: wchar link problems building for jaguar
>>>> Date: Tue, 4 Nov 2003 15:57:12 -0800
>>>>
>>>> On Oct 28, 2003, at 4:50 PM, Thane Norton wrote:
>>>>
>>>>> We seem to have a solution for building a 10.1.5 thru 10.3 binary
>>>>> using
>>>>> XCode and GCC 3.3. Can't claim it will work for everyone, but it
>>>>> got
>>>>> our
>>>>> stuff up and running.
>>>>
>>>> I have a slightly different solution to this problem, which I
>>>> posted in
>>>> another thread "10.2 deployment issues".
>>>>
>>>> In a nutshell, there seems to be a problem with the way Xcode sets
>>>> up
>>>> include paths when you're doing cross-development builds, such that
>>>> some important C++ headers (notably c++config.h) are read from the
>>>> Panther /usr/include tree instead of the SDK's. You can fix this by
>>>> adding the following to your target's Header Search Paths build
>>>> settings:
>>>>
>>>> /usr/include/gcc/darwin/3.3/c++
>>>> /usr/include/gcc/darwin/3.3/c++/ppc-darwin
>>>> /usr/include/gcc/darwin/3.3
>>>
>>>
>>>
>>> Our Xcode project has 49 targets (individually built static libs).
>>>
>>> What's the shortest route to getting the right paths activated
>>> across all the targets other than pasting the characters above into
>>> all of them?
>>>
>>> Can I set up some kind of global environment variable/value that
>>> can then be referenced in all the targets?
>>>
>>> Will a future Xcode release deal with this more cleanly (ie is it
>>> considered a bug yet?)
[demime 0.98b removed an attachment of type application/pkcs7-signature which had a name of smime.p7s]
_______________________________________________
xcode-users mailing list | email@hidden
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/xcode-users
Do not post admin requests to the list. They will be ignored.