[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