[cmake-developers] push of LinkOptionsCommand topic branch

Steve Wilson stevew at wolfram.com
Wed Feb 5 12:36:31 EST 2014


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”]?      I suppose it could use linkFlags.   I could just revert the call to GetTargetFlags to use vars[“LINK_FLAGS”].   I was trying to avoid the case of getting the link flags for the target twice.   Ie getting them once in vars[“LINK_FLAGS”] and then again in AddLinkOptions().

> 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?

> 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.
Is there some design document that you are using to make these determinations?   I’m not trying
to cause problems, I’m just saying that adding a library as a linker flag is a perfectly normal/legitimate
thing to do coming from a Makefile world (or other build environment world).  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.

> On GNU, you can do this:
> 
> add_executable(foo foo.cpp)
> target_link_options(foo PRIVATE -Wl,--ignore-unresolved-symbol,main)
> 
> and write a foo.cpp which does not define main.

I agree this would make a good test, but it doesn’t change my earlier comment.    Adding a library via
a linker option is a perfectly valid use of linker options.   If it wasn’t, the linker (or the compiler driver) wouldn’t
support it.

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

> 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.

I don’t think that this suggestion is the right way to go.   I will of course defer to your judgement, but I don’t agree.

Perhaps there is a detail I’m missing about how the code makes a distinction between —no-undefined and
-Wl,—no-undefined.


> The documentation should possibly be clear that the contents of LINK_OPTIONS 
> should be suitable for passing to the driver, not directly to the linker.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20140205/5b121aa7/attachment-0002.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 236 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20140205/5b121aa7/attachment-0002.sig>


More information about the cmake-developers mailing list