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