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 _______________________________________________ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake