[CMake] TARGET_LINK_LIBRARIES build types and assorted .vcproj "fixes"

Bill Hoffman bill.hoffman at kitware.com
Wed Apr 4 09:46:53 EDT 2007


Joshua Jensen wrote:
> Hi.
>
> After researching a number of build systems, I settled upon CMake.  As 
> I began converting my projects to CMakeLists.txt, I ran into a number 
> of issues (discussed below).  At the moment, I'm only trying to bring 
> the Visual Studio build up.  I don't profess any of my "fixes" are the 
> right solution, but after digging through the mailing list and a bunch 
> of Google searches, I could identify no better solution.  I can 
> provide a diff for interested parties (but I'll need a little help 
> with the correct CVS commands) or my CMakeLists.txt files.
>
> I'd passed over CMake in the past, and I'm glad it caught my eye this 
> time around.  It is a most excellent product, and I look forward to 
> working with it more.
>
> Thanks.
>
> Joshua Jensen
>
> -----------
>
> Windows-cl.cmake:
>
> * Reservation of a 10 megabyte stack in Windows-cl.cmake is overkill.  
> The default is 1 megabyte.  Why is this here?  I removed it.
I guess this goes back to the projects that CMake was originally 
developed for.   But now due to backward compatibility I don't think we 
can change it, but we should think of some way to make it easier for a 
project to change.  You can change them now with this variable:

CMAKE_USER_MAKE_RULES_OVERRIDE

If you set that in your project BEFORE the PROJECT command to a file, 
you can set your own _INIT variables to anything you want.
> * Visual Studio 2005 doesn't understand /MACHINE:I386.  I changed it 
> to /MACHINE:X86.
I have not seen a warning or had a program not work, and we use VS 2005 
all the time.   This does not seem to be a problem....
> * All /debug linker entries were changed to /DEBUG.  CMake deals with 
> these in a case sensitive fashion.  The Visual C++ linker does not, 
> but all documentation has them all caps.
>
I have not seen a problem with this, and I use VS 2005 and debug all the 
time.
> cmGlobalVisualStudio7Generator.cxx:
>
> * I commented out the explicit checks for config names of Debug, 
> Release, MinSizeRel, and RelWithDebInfo.  In my projects, I use 
> configs like Debug, Release, Profile, Armor, Release LTCG, and so on.  
> Commenting out the explicit checks allows generation of those configs 
> into the resulting .vcproj file.
>
This is probably a good change, can you create a bug entry for this.   
The big issue will be that other generators like Xcode and VS 6 will not 
know about the config names.
> cmLocalVisualStudio7Generator.cxx:
>
> * Added support for .vcproj entries to help unclutter the command 
> line: OptimizeReferences, EnableCOMDATFolding, 
> GenerateDebugInformation, and TargetMachine.
I am not sure what you did here?
> * Commented out explicit checks for config names.
Is this the same as your first bullet item?
> * Fixed a bug preventing the user from adding the linker flag /DEBUG 
> to the link line.  /D is considered a #define.  Adding an explicit 
> check fixes this issue.
>
A define can be added to the linker?  If I do link /help with vs 2005 I 
get this:

 usage: LINK [options] [files] [@commandfile]

   options:
.....
 /DEBUG
.....

The lower case version seems to work as well.

> General:
>
> * Added support for TARGET_LINK_LIBRARIES(Target config::ConfigName 
> libraries).  This is probably the wrong way to go about doing it, but 
> it works, and I made sure it was backward compatible with the 
> TARGET_LINK_LIBRARIES options 'debug' and 'optimized'.  Different 
> configurations require different external libraries, and specifying 
> those link libraries per config helps immensely.  Sadly, other 
> important commands like INCLUDE_DIRECTORIES and LINK_DIRECTORIES are 
> not config-sensitive for .vcproj files.  I need to look into that 
> more, unless someone has a better idea.  This was, in part, talked 
> about in this thread: 
> http://public.kitware.com/pipermail/cmake/2004-August/005464.html
>
> For instance:
>
> TARGET_LINK_LIBRARIES(MyApp config::Debug wxmsw28d_core wxbase28d 
> wxmsw28d_adv wxmsw28d_html wxbase28d_xml wxexpatd wxmsw28d_xrc 
> wxmsw28d_gl wxjpegd wxpngd wxzlibd wxregexd wxdockitd wxmsw28d_propgrid)
> TARGET_LINK_LIBRARIES(MyApp config::Release wxmsw28_core wxbase28 
> wxmsw28_adv wxmsw28_html wxbase28_xml wxexpat wxmsw28_xrc wxmsw28_gl 
> wxjpeg wxpng wxzlib wxregex wxdockit wxmsw28_propgrid)
> TARGET_LINK_LIBRARIES(MyApp config::ReleaseFinal wxmsw28_core wxbase28 
> wxmsw28_adv wxmsw28_html wxbase28_xml wxexpat wxmsw28_xrc wxmsw28_gl 
> wxjpeg wxpng wxzlib wxregex wxdockit wxmsw28_propgrid)
This sounds interesting, please create a bug report feature request so 
it is not lost.

-Bill




More information about the CMake mailing list