On 5/11/2012 5:56 AM, Stephen Kelly wrote:
>> (2) Document the property as using that flag *and* suppressing
>> use of CMAKE_SHARED_LIBRARY_${lang}_FLAGS altogether.
>
> Hmm, I don't think I understand why this is necessary.
>
>> (3) Leave the property undefined even for shared libs and let
>> the project set the property to get new behavior.
>
> That's not compatible with people thinking they'll get PIC shared libraries
> by default already though.
Yes, it is. When the property is not set then the current behavior
of using CMAKE_SHARED_LIBRARY_${lang}_FLAGS will NOT be
suppressed and nothing will change, at least in my proposal.
> I don't see why changing that is necessary.
With your branch currently I get -fPIC twice on the compile line.
One comes from cmLocalGenerator::AddSharedFlags and one
comes from AddPositionIndependentFlags. Furthermore on the
link line I get -fPIC once from the
<CMAKE_SHARED_LIBRARY_C_FLAGS>
placeholder in the rule to link shared libraries.
The new property needs to replace the old approach to provide -fPIC,
not add to it. However, we need at least two things to be preserved
for compatibility:
(1) If a project *sets* CMAKE_SHARED_LIBRARY_${lang}_FLAGS
then its value must be used where it has previously been used.
(2) If a project *reads* CMAKE_SHARED_LIBRARY_${lang}_FLAGS
then it must get the value that it previously got.
Perhaps a policy could be introduced for those two cases to allow
permanent transition to the new property, but they need to be handled.
-Brad
--
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
