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

[Brad King]

On 05/29/2012 12:16 PM, Stephen Kelly wrote:
> Done, though I left some notes in the commit for now. It seems the existing 
> variable is used for more than just PIC equivalents.

Thanks for going through all the platforms!

I think the only non-PIC instances are for Watcom and Embarcadero
where options "-bd" and "-tD", respectively, tell the compiler that
the object file is intended for inclusion in a DLL, and for SCO
where -belf is required for shared libraries.  Did you notice any
others?

The solution is to generalize the policy further.  It's short
description "Ignore CMAKE_SHARED_LIBRARY_<Lang>_FLAGS variable." is
already correct.  The OLD behavior should continue to be the same,
using the modified variable value and ignoring all new variables.
The NEW behavior must be generalized to use multiple new platform
variables, one for each purpose originally served by the old
variable.  So far we've identified:

- CMAKE_${lang}_COMPILE_OPTIONS_PI{C,E}, controlled by the
  POSITION_INDEPENDENT_CODE target property.  You already did
  this one.

- CMAKE_${lang}_COMPILE_OPTIONS_DLL, used for any object intended
  for inclusion in a dynamic library e.g. -bd, -tD, or -belf.
  This is new to our design.  For now we can just hard-code its
  use on SHARED and MODULE libraries but some day we could add a
  property for it so it can be set in an OBJECT library whose
  objects will be used in a shared library.

- Any others you noticed?

Please also try updating the CMP0018 documentation accordingly.

Other comments on the topic: Use of ExpandListArgument and
EscapeForShell looks good, thanks.  I think it may be simpler
to use GetSafeDefinition for the _COMPILE_OPTIONS_ variable
lookups so they can simply be left unset on platforms that do
not need them.  Then we can remove CMAKE_SHARED_LIBRARY_C_FLAGS
from platforms where it is empty anyway.

Your change to CMakeCXXInformation will be needed in Fortran too.

Thanks,
-Brad