Re: Passing Build Settings to an included (Library) project
Re: Passing Build Settings to an included (Library) project
- Subject: Re: Passing Build Settings to an included (Library) project
- From: Andreas Grosam <email@hidden>
- Date: Tue, 16 Apr 2013 16:55:03 +0200
On 16.04.2013, at 15:55, Jeffrey Walton wrote:
> On Tue, Apr 16, 2013 at 9:21 AM, Andreas Grosam <email@hidden> wrote:
>>
>> On 15.04.2013, at 20:45, David Hoerl wrote:
>>
>>> iOS app, includes a library project. In Xcode 3, I recall you could add a "User Defined" Build Setting in the app target, and through some magic incantation the included Library project would see those settings. [Then again, maybe I just dreamed I got this to work.]
>>>
>>> So, Question, is there a way to pass Build Settings from App to Library project?
>>
>> IMHO, most libraries' build settings are *private* to the library. That means, another project should not be able to override settings of a library.
>>
> This is probably bike shedding, but I often need to modify CFLAGS and
> CXXFLAGS to test a library during acceptance testing; and (if
> accepted) keep many of those modifications through the
> build/engineering process.
Why would one have to do this? How about running the unit tests of the library in order to test it? Doesn't cover an existing "Debug" and "Release" build your need to set CXXFLAGS?
An example why modifying build settings might be problematic:
Some older projects used to set optimization level -O2. That might be for a reason, probably due to an optimization bug in the compiler when using -03.
I've recently enabled LTO for one of my library projects. That flag used to be problematic (the linker issued errors and warnings) under certain scenarios. Now, with most recent compiler and libraries the product has passed all test. The full set of build settings are considered *frozen* and *private*. Modifying the compiler options from some client through CFLAGS, possibly the more exotic ones, is not fully tested and may break it. Likely nobody else is using your set of build settings so you won't get notified about issues that others would have detected already.
Andreas
>
> You have to know how/when/where a third party library will fail and
> take appropriate steps to remediate. If not, its your app that takes
> the bug report and possibly leaks sensitive information, not the third
> party library.
>
> Jeff
_______________________________________________
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