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

[Joshua Jensen]

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.
* Visual Studio 2005 doesn't understand /MACHINE:I386.  I changed it to 
/MACHINE:X86.
* 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.

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.

cmLocalVisualStudio7Generator.cxx:

* Added support for .vcproj entries to help unclutter the command line: 
OptimizeReferences, EnableCOMDATFolding, GenerateDebugInformation, and 
TargetMachine.
* Commented out explicit checks for config names.
* 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.

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)