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.
The Watcom WMake tool has trouble running commands in paths that have
parentheses. We already convert most commands to a shortpath for Watcom
if the path contains a space, but the use of $(CMAKE_COMMAND) hides the
true path from that conversion. Factor the shortpath conversion code
out into a new ConvertShellCommand method. Teach it to convert paths
that contain parentheses as well as spaces. Use the new method to
convert the value of $(CMAKE_COMMAND) and other helper variables.
The MFC test's mfc1 directory was a "VS-MFC-wizard-generated"
starter MFC app, using VS 7.1 as the generator. There's one define
used in the generated rc file that was not available back in the
VS6 days... Put a conditional define in here based on _MSC_VER
to enable the test app to build on VS6 dashboards.
Teach cmComputeLinkInformation to generate the "-framework" option as a
separate link item preceding the actual framework name. Then escape the
framework name to pass as an argument through a shell. This fixes the
link line for frameworks with spaces in the name.
The build system generators that call cli.GetItems() and generate the
final list of items on the link line already handle escaping correctly
for items that are paths. However, for raw link items like "-lfoo" they
just pass through to the command line verbatim. This is incorrect. The
generators should escape these items too. Unfortunately we cannot fix
that without introducing a new CMake Policy because projects may already
be passing raw link flags with their own escapes to work around this
bug. Therefore we punt on this bug for now and go with the above fix.
Eclipse doesn't handle this case well. When doing out-of-source builds
we create a linked resource which points to CMAKE_SOURCE_DIR, so the
user can browse the source dir in Eclipse. This is not possible
when the build dir is a subdir of the source dir.
Alex
467ee36 Check plugin variables are defined before warning.
4571ea6 Don't resolve directories; are never relative.
9cfc920 Match fixup_qt4_executable with documentation.
CommandLineArguments.cxx:
remark #181: argument is incompatible with corresponding format
string conversion
SystemInformation.cxx:
remark #193: zero used for undefined preprocessing identifier "_WIN32"
warning #177: variable "Regebx" was declared but never referenced
SystemTools.cxx(375):
remark #444: destructor for base class "std::vector<char*>" is not virtual
class kwsysDeletingCharVector : private kwsys_stl::vector<char*>
Author: Hans Johnson <hans-johnson@uiowa.edu>
Change-Id: Ibc899c3ba14990158ef7bbabace4b435b22495c3
Build a simple, do-nothing VS 7.1 MFC wizard generated app
with CMake.
Build it two different ways via ExternalProject, one with
CMAKE_MFC_FLAG set to 1 for linking to MFC statically, and
one with CMAKE_MFC_FLAG set to 2 for linking to the shared
MFC dlls.
Validate that the install tree of the static build has only
one *.exe file in it and nothing else. Also validate that the
install tree of the shared library build has multiple files in
it (no less than 3) and that they are only of the expected types
*.exe, *.dll and *.manifest.
This commit does not address the issue reported in #11213,
it merely adds a test that may be used to show that the
bug report is valid. After this commit, the MFC test should
fail on any dashboard machines that have MSVC defined, but
cannot build an MFC app. We can then analyze that failure
data as input to solving the issue.
KWSys Robot
David Cole
Eric NOULARD
Stephen Kelly
Alex Neundorf
Brad King
Mike McQuaid
Robert Dailey