[cmake-developers] push of LinkOptionsCommand topic branch

Stephen Kelly steveire at gmail.com
Wed Feb 5 12:51:48 EST 2014


Steve Wilson wrote:

> Let’s try all this again.    I have a couple questions.
> 
> On Feb 4, 2014, at 3:41 AM, Stephen Kelly
> <steveire at gmail.com> wrote:
> 
>> 2) The change to cmNinjaNormalTargetGenerator seems incorrect. Should
>> linkFlags should be used with AddLinkOptions?
> 
> Do you mean linkFlags vs vars[“LINK_FLAGS”]?  

Yes, that's what I meant. The linkFlags variable is populated, but not used.

I may be mis-reading the code. I'll have a closer look tomorrow.

>> 3) Documentation title underlines should be as long as the title, not 3
>> dashes longer.
> 
> Ok great.   What specifically are you referring to with this comment?

 diff --git a/Help/command/add_link_options.rst 
b/Help/command/add_link_options.rst
 index 60a981d..a4e2955 100644
 --- a/Help/command/add_link_options.rst                                                                                                                                                                            
 +++ b/Help/command/add_link_options.rst                                                                                                                                                                            
 @@ -1,5 +1,5 @@                                                                                                                                                                                                    
  add_link_options                                                                                                                                                                                                  
 --------------------                                                                                                                                                                                               
 +----------------                                                                                                                                                                                                  
                                                                                                                                                                                                                   
  Adds options to the link commands of targets.                                                                                                                                                                     
                 

Repeats for other docs and titles.

> 
>> 4) Tests should avoid bad practices like using target_link_options to add
>> libraries. Instead try to choose suitable link flags for the tests.
> 
> I’m having a little trouble with your notion of ‘bad practices.’   I’m
> sure you have good reasons for making the determination that they are bad
> practices, but to me they seem somewhat arbitrary.

Generally, cmake managed the libraries that are linked to (specified via 
target_link_libraries) so that it can determine the proper link line, and 
set up dependencies in the buildsystem so that a change in the library 
causes a rebuild. Specifying a library in target_link_options would bypass 
that. I don't know of a reason that 

 target_link_options(tgt PRIVATE -llibsomething)

is better than

 target_link_libraries(tgt PRIVATE -llibsomething)

and should be encouraged. If there is a reason, maybe I just don't know 
about it.

> Is there some design document that you are using to make these
> determinations?

No, just awareness of the cmake feature and existing commands etc for 
handling libraries, and some awareness of the reason to use the particular 
commands. I would say that using target_link_options() to link to libraries 
should be discouraged in the documentation of that command unless there's a 
particular reason to recommend it in some case?

> I realize that CMake has different mechanisms for explicitly
> handling libraries, but the point isn’t to handle the library, the point
> was just to pass a reasonable linker option.

Ok, I'm not aware of a reason to do that, but if there is a good one, it 
might be worth adding it to the documentation.

>> On GNU, you can do this:
>> 
>> add_executable(foo foo.cpp)
>> target_link_options(foo PRIVATE -Wl,--ignore-unresolved-symbol,main)

> Does that make sense?  How should I determine what is bad practice in the
> face of what is reasonable?

I would say that tests and documentation should assume the use of the CMake 
features for managing the linked libraries. 

Additionally, I find the test with the --ignore-unresolved-symbol option 
preferable because it does not rely on the existence of outside files.

>> 5) Regarding what I said before about accepting -Wl,--no-undefined versus
>> accepting --no-undefined, I think the case of flags with arguments as
>> above shows that only the -Wl, prefixed case should be accepted (as your
>> branch already does).
> 
> However, what if someone changes the mechanism that picks the linker so
> that instead of using the compiler
> driver to drive the link stage, they use the actual linker?   I don’t do
> such a thing with my build systems and
> in all probability the majority of users would never need to make such a
> change.   However, if I, for some reason, *did* need to change CMake so
> that the link stage invoked the linker directly, I would absolutely expect
> the link options commands to pass whatever linker option I deemed
> necessary to the linker.

Indeed. Brad, any input here? Is this even possible?

Thanks,

Steve.





More information about the cmake-developers mailing list