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: Jeffrey Walton <email@hidden>
- Date: Tue, 16 Apr 2013 11:21:30 -0400
On Tue, Apr 16, 2013 at 10:55 AM, Andreas Grosam <email@hidden> wrote:
>
> 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?
There's a number of reasons to override developer provided build
settings. For example, suppose the developer mixes and matches signed
and unsigned types. A nasty side effect in C is that the signed value
is promoted to an unsigned value, so that -1 > 1 after promotion. This
would be caught by -Wconversion, but the developers often do not
supply the warning or the self test to verify the behavior.
There's plenty more similar examples.
> Doesn't cover an existing "Debug" and "Release" build your need to set CXXFLAGS?
That's part of it, but there's much more to properly configuring third
party libraries (in addition to the app).
https://www.owasp.org/index.php/C-Based_Toolchain_Hardening.
> 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.
Agreed.
> 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.
If your library contains illegal code, LTO could remove that illegal
code at runtime (yet pass self tests). Signed overflow and illegal
shifts come to mind. "Effects of Link Time Optimizations in Illegal
Libraries," http://gcc.gnu.org/ml/gcc-help/2013-03/msg00351.html.
> 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.
The library was likely broken before you got to it. That's why we have
to test them before using them. There's no need to kill the messenger
when the library is at fault :)
> Likely nobody else is using your set of build settings so you won't get notified about issues that others would have detected already.
Yes, users of the library should provide the feedback to the developer
or project. I feel its a user's obligation.
Whether the developer or project uses the feedback is another can of
worms, though. I can point you to examples where the feedback was
provided but ignored. Later, the library suffered remote code
execution that would have been remediated following the provided
feedback. You can lead them to water, but you can't make them drink :)
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