Move the Version member to the top cmLocalVisualStudioGenerator class
and set it consistently for instances created by all the global
generator versions. Use an enumeration type with values scaled by a
factor of 10 so we can handle VS 7.1 without out-of-order numbers.
VS 7.1 support for SuppressStartupBanner was broken by commit 25116a3c
(Fix CMAKE_VERBOSE_MAKEFILE for VS10 vcxproj files, 2011-10-11) because
it assumed comparison of VS version numbers works. Now it does.
Xcode 2.x forgets to create the target output directory before linking
the individual architecture pieces of a universal binary for the target
KWIML_test. Then it passes the directory to -L and -F options when
linking the and warns that the directory does not exist. We work around
the problem by using a pre-build rule on the target to create the output
directory.
The Sun compiler does not document support for SCN*8 format (%hh*).
It works only on platforms that happen to provide a runtime library
that supports the format.
KWIML defines format string macros matching the fixed-sized types. This
test checks that they behave as expected and that the arguments match
the *sizes* expected by the format strings.
I've just found out that use of FindBISON.cmake shipped with CMake 2.8
on system where bison++ is default bison executable (e.g. Debian Linux)
will result in corrupted CMakeCache.txt file and parse error due to
"Offending entry"
As FindBISON.cmake logic used to obtain installed bison executable
version is tailored to match only the message used in GNU Bison it fails
on absolutely different Bison++ version message and whole version
message including \n characters is stored into BISON_VERSION which is
then dumped into CMakeCache.txt, so everything after first \n character
makes "Offending entry".
Handing th std::string instead the char* to the find()
reduces the time from 17 to 15 seconds (for a 1000 times loop of a
relatively small file), which is around 10 percent.
Alex
There are multiple/many places in KDE where the developer includes
moc_foo.cpp, and expects moc to run on foo.cpp, instead of foo.h.
He should use foo.moc, but right now this is handled by automoc4,
so we must stay compatible. So support this too, but warn about
it.
Alex
InstallRequiredSystemLibraries does not install any dlls when
used with VS 6 dashboards. Modify the ValidateBuild script to
expect only 1 file when building with VS 6.
Using "-DCMAKE_INSTALL_PREFIX=<INSTALL_DIR>" does not work when
<INSTALL_DIR> evaluates to a long enough string. However, using
"-DCMAKE_INSTALL_PREFIX:PATH=<INSTALL_DIR>" does work, even with
the longer strings. So: make sure to include the ":PATH" when using
this construct with ExternalProject calls so that they may install
to the proper location on VS 6 builds. All existing calls that match
"CMAKE_INSTALL_PREFIX.*INSTALL_DIR" include the ":PATH" after this
commit.
By the way: https://twitter.com/DLRdave/status/134339505397309440
Use expected values for the UseOfMfc xml element in
VS 10 .vcxproj files.
CMAKE_MFC_FLAG=1 maps to "Static"
CMAKE_MFC_FLAG=2 maps to "Dynamic"
all other values map to "false"
Thanks to Randy Schott and McBen for their patches which
served as inspiration and motivation for getting this done.
See also http://public.kitware.com/Bug/view.php?id=11224
The mfc app in the test was generated by the VS 7.1 wizard,
and due to changes in VS since then, the values used for WINVER
and _WIN32_WINNT caused compile errors when built with VS 10
or later. Change them to values appropriate for targeting
Windows XP or later when building with VS 10 or later.
See http://msdn.microsoft.com/en-us/library/6sehtctf.aspx
for more info.
Brad King
KWSys Robot
Ondrej Balaz
Alex Neundorf
Stephen Kelly
Mateusz Loskot
David Cole
Dan Kegel
Eric NOULARD