[CMake] How to append arbitrary linker options?

[Brad King]

Bartlett, Roscoe A wrote:
> The hack:
> 
>   set(CMAKE_CXX_LINK_EXECUTABLE
>    "${CMAKE_CXX_LINK_EXECUTABLE} ${NASTY_FLAGS}")
> 
> does not work because my libraries still come after these flags.

Read my suggestion more carefully.  I'm not setting
CMAKE_EXE_LINKER_FLAGS.  I'm setting the variable from which the
Makefiel generators compute the link rule.  There is a <LINK_LIBRARIES>
token in the string which gets replaced by the computed library set.  My
suggestion puts flags in the rule that appear after the token.

It may be a moot point if you need this to work for the VS IDE since
that generator does not use this rule variable.

> However, the second suggestion of creaking the 'last' library seems
> to be working. I am a little concerned about using:
> 
>     target_link_libraries(last ${NASTY_FLAGS})
> 
> because the documentation for target_link_libraries(...) does not
> seem to suggest that you can do this. I just says that you can list
> other libraries as:
> 
>     target_link_libraries(<target> [lib1 [lib2 [...]]]
>                           [[debug|optimized|general] <lib>] ...)
> 
> it does not suggest that you can pass in any old arbitrary link options.

Wow, you're actually paying attention to the documentation instead of
just assuming it will work because it does in the current
implementation.  If all users did this it would be much easier to
maintain backwards compatibility :)

I don't think we originally intended for flags to be allowed here, but
it has always worked.  Last year when I re-implemented link line
computation I had to do a lot of work to make sure this undocumented
behavior was preserved.

> Will this behavior that seems to be working be preserved and can it
> be officially documented?

I've updated the documentation.

/cvsroot/CMake/CMake/Source/cmTargetLinkLibrariesCommand.h,v  <--
Source/cmTargetLinkLibrariesCommand.h
new revision: 1.20; previous revision: 1.19

> Will this work on MS Windows Visual Studio and with other generators?

Yes, at least from CMake's point of view.  The flags will end up at the
end of the AdditionalDependencies field in the project file.  I don't
know what VS will do with non-libraries in this field though.

> This is somewhat of a hack but until CMake can address every issue
> automatically (like Fortran libraries in mixed-language programs and
> appending -lm for C programs), we need to be able to append arbitrary
> libraries at the end of a link line.

The math library (-lm) is part of the C runtime library, but is optional
on UNIX compilers.  If a library doesn't include <math.h> (or complex,
etc.) then it doesn't need to link to the math library.  Many projects
just write:

  if(UNIX)
    link_libraries(m)
  endif(UNIX)

so that all targets link to it.  This may not work in mixed-language
projects though (and the command is deprecated).  Clearly this is not an
option for the Fortran runtime library.

Currently we use automatic selection of the compiler through which to
perform linking in order to get the proper runtime libraries.
Unfortunately this does not work for Fortran/C++ mixed cases, so
currently we require authors to deal with it.

In order to deal with this automatically we'll have to define an
explicit notion of runtime libraries for each language.  CMake would
automatically link an executable to the runtime libraries of all
languages it uses.  There are lots of subtle issues here, like knowing
the runtime library names for all the toolchains, knowing which ones are
implicitly handled by a given compiler, and transitive behavior for user
libraries (when a library uses Fortran but the executable doesn't).

-Brad