[cmake-developers] Adding logic to CMake for -fPIE and -fPIC

Stephen Kelly steveire at gmail.com
Thu May 17 08:36:35 EDT 2012


Brad King wrote:

> On 05/13/2012 04:24 PM, Stephen Kelly wrote:
>> I've added a 'WIP: Experiment with backwards compatibility.' patch to my
>> gitorious clone.
>>
>> +      // TODO: Is there a 'not set' state for properties?
>> +      // We should handle that differently to boolean False.
> 
> There is a "not set" state for properties.  Use the raw "GetProperty"
> method.  If it returns a NULL pointer then the property is not set.

Good to know, thanks.

> 
>> I think it should be possible to do this by either setting
>> a default in the CMake files, or handling the setting of properties of
>> names matching CMAKE_SHARED_LIBRARY_${lang}_FLAGS specially to also store
>> a default on first call (which will come from the CMake internal files, I
>> guess?)
> 
> That gives me an idea on how to add a policy for this without triggering
> on every shared library.  Trigger it on projects that change the flags.
> Since POSITION_INDEPENDENT_CODE's default behavior is the same as the
> current default CMAKE_SHARED_LIBRARY_${lang}_FLAGS there is no problem
> for projects that do not change the flags.
> 
> Start by implementing POSITION_INDEPENDENT_CODE and initialize it to
> true for shared libraries just as in your original proposal.  There is
> no need for special "not set" behavior as in my previous suggestion.
> 
> After each language is enabled (cmGlobalGenerator::EnableLanguage)
> save the initial CMAKE_SHARED_LIBRARY_${lang}_FLAGS in a C++ structure.

> <snip>

> For executables CMake can first look for PIE and then for PIC.

Done and re-pushed to my clone. I still have to write the unit tests, but I 
think it can be reviewed again at this point.

Thanks,

Steve.







More information about the cmake-developers mailing list