On 05/25/2012 04:47 PM, Stephen Kelly wrote:
> I'm also not completely certain about the change to the try_compile behavior
> in the branch. Could there be any reason to use
> set(CMAKE_POSITION_INDEPENDENT_CODE ON) but want to do a try_compile without
> -fPI{C,E} ? My guess is no, because one would do the try_compile before
> conditionally setting that property, I guess.
Since project's don't currently set CMAKE_POSITION_INDEPENDENT_CODE
there is no compatibility problem. I think it is okay to honor that
for try_compile. It is more representative of how the sources will
actually be compiled in the calling project.
The current topic looks pretty good so far. There is some more work
to be done. Please see the block at the bottom of this message for
the documentation I recommend using for CMP0018.
Look at the logic in cmLocalGenerator::AppendFeatureOptions for
handling of _COMPILE_OPTIONS_ values. We need to use
ExpandListArgument to ensure that options are separated as
CMake-style lists instead of whitespace. That is the convention
I'm establishing for "COMPILE_OPTIONS" platform variables. It will
not make a difference for single-argument options like "-fPIC" but
could if some platforms have multi-argument options.
Before merging we will need to add the equivalent to the hunk
+ set(CMAKE_${lang}_COMPILE_OPTIONS_PIC "-fPIC")
+ set(CMAKE_${lang}_COMPILE_OPTIONS_PIE "-fPIE")
on all necessary platforms. The policy can't be per-platform.
You already have a TODO comment for this.
Thanks,
-Brad
------------------------------------------------------------------------
Ignore CMAKE_SHARED_LIBRARY_<Lang>_FLAGS variable.
CMake 2.8.8 and lower compiled sources in SHARED and MODULE libraries
using the value of the undocumented CMAKE_SHARED_LIBRARY_<Lang>_FLAGS
platform variable that contained flag to request position independent
code, such as -fPIC. CMake 2.8.9 and higher prefer instead to use the
POSITION_INDEPENDENT_CODE target property to determine what targets
should be position independent, and unspecified means to select the
flags while ignoring CMAKE_SHARED_LIBRARY_<Lang>_FLAGS.
The default for either approach produces identical compilation flags,
but if a project modifies CMAKE_SHARED_LIBRARY_<Lang>_FLAGS from its
original value this policy determines which approach to use. The OLD
behavior for this policy is to ignore the POSITION_INDEPENDENT_CODE
property for all targets and use the modified value of
CMAKE_SHARED_LIBRARY_<Lang>_FLAGS for SHARED and MODULE libraries.
The NEW behavior for this policy is to ignore
CMAKE_SHARED_LIBRARY_<Lang>_FLAGS whether it is modified or not and
honor the POSITION_INDEPENDENT_CODE target property.
------------------------------------------------------------------------
--
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
