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

[Joshua Jensen]

Bill Hoffman wrote:
> Joshua Jensen wrote:
>> * 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.
Okay, I had missed that one.  That is interesting.  Is there a command 
to specifically remove a given flag?
>> * 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....
I have posted, in lieu of a patch (since I'm not sure of the exact 
format it should be in... I haven't touched CVS in years), my changes at 
http://wwhiz.com/JoshCMakeDiffs.zip .  If these are unzipped over the 
top of the latest CVS, you'll have my build.

Now, the primary reasons for using the correct flag is to 1) use the the 
correct flag and 2) allow the cmLocalVisualStudio7GeneratorLinkFlagTable 
structure to resolve the .vcproj "TargetMachine" entry.  In filling in 
the correct entry, the target machine shows up in the GUI.  From the 
JoshCMakeDiffs.zip, see Source/cmLocalVisualStudio7Generator.cxx, line 365.
>> * 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.
Yes, you are right, but the problem is resolution within the 
cmLocalVisualStudio7GeneratorLinkFlagTable, where specified flags are 
interpreted in a case sensitive fashion.  The documentation refers to 
the command-line option as /DEBUG, so when I added the 
GenerateDebugInformation entry to 
cmLocalVisualStudio7GeneratorLinkFlagTable 
(Source/cmLocalVisualStudio7Generator.cxx, line 364), I wanted it to be 
consistent with what the user would tend to choose.  In reality, the 
link flags should be considered non-case-sensitive, and this wouldn't be 
an issue.
>> 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.
I'll be working on getting my project up under Xcode soon, and it will 
be my desire to make that work with the varied configurations.  Adding 
them to the VS6 generator doesn't look hard, either.
>> 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?
Source/cmLocalVisualStudio7Generator.cxx, lines 362-365.
>> * Commented out explicit checks for config names.
> Is this the same as your first bullet item?
Yes.
>> * 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:  The lower case version seems to work as well.
If you see Source/cmLocalVisualStudio7Generator.cxx, line 1740, you'll 
see a change that prevents /DEBUG from being added to this->Defines.  
Granted, this does not happen with /debug, but my case of sticking with 
the documentation and help case sensitivity is above.

Lines 776-780 and lines 850-854 were commented out, as adding 
GenerateDebugInformation is not dependent on config anymore.  It's 
dependent on finding /DEBUG on the linker command line.
>> 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.
Most other changes in the file I posted revolve around this.  I'll log a 
feature request soon.

Josh


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://public.kitware.com/pipermail/cmake/attachments/20070404/56f60ec3/attachment.htm