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.
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
