Brad King wrote:
> 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 see. I misread you before.
>
>> 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.
I've added a 'WIP: Experiment with backwards compatibility.' patch to my
gitorious clone. 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?)
If that approach is not workable, I guess we'll have to go with a policy.
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
