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

[Brad King]

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.

> 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.
Then in the generator before calling AddSharedFlags, compare the value
of the variable to the saved value to see if it changed.  If not, then
just ignore the value and use the POSITION_INDEPENDENT_CODE as normal
(make sure <CMAKE_SHARED_LIBRARY_${lang}_FLAGS> expands to empty).
If the project did change the value then trigger the policy.  The OLD
behavior is to use the flags and ignore POSITION_INDEPENDENT_CODE.  The
NEW behavior is to use POSITION_INDEPENDENT_CODE and ignore the flags.


I remembered that a while back I started a convention for feature->flag
mapping.  Instead of variable names like "CMAKE_..._${lang}_FLAGS"
containing space-separated values, we can use names like
"CMAKE_${lang}_COMPILE_OPTIONS_..." containing ;-seprated values.  The
name and value form is consistent with plans I mention here:

  http://www.cmake.org/Bug/view.php?id=6493#c21559

for a future alternative to the COMPILE_FLAGS property.  The name
"CMAKE_${lang}_COMPILE_OPTIONS_IPO" is the first one, for the
INTERPROCEDURAL_OPTIMIZATION property.  For the
POSITION_INDEPENDENT_CODE property we could use:

 set(CMAKE_${lang}_COMPILE_OPTIONS_PIC "-fPIC")
 set(CMAKE_${lang}_COMPILE_OPTIONS_PIE "-fPIE")

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

-Brad