Use cmVisualStudioSlnParser in GenerateBuildCommand() to provide correct
command line for MSBuild even when target project is stored in a
subdirectory.
Create class cmVisualStudioSlnParser as a generic parser for Visual
Studio .sln files. Implement minimum functionality but keep class
extensible. Add tests for the class.
Extend the cmGlobalGenerator::GenerateBuildCommand virtual method
signature with a "projectDir" parameter specifying the top of the
project build tree for which the build command will be generated.
Populate it from call sites in cmGlobalGenerator::Build where a
fully-generated build tree should be available.
It is considered an error if the INTERFACE_INCLUDE_DIRECTORIES contains
a directory which does not exist, which indicates a programmer error
by the upstream, or a packaging error.
One of the RunCMake.CompatibleInterface tests also needs to be updated
due to this change. Non-existant includes were used in the test, but
are not needed.
Check that source and binary directories are not part of the
INTERFACE_INCLUDE_DIRECTORIES for installed IMPORTED targets.
This is limited to directories which do not contain generator
expressions to evaluate. Such paths can only be checked at time
of use of the imported target, which will be done in a follow up
patch.
The VS version we generate in the .sln header is used by VS when opening
the file through Windows Explorer and possibly elsewhere. Fix our
generators to use version strings known to VS to avoid a drop-down box.
For VS 10, since commit 4f96af44 (Fix VS 10 .sln files for Windows
Explorer, 2009-10-22) we use "Visual Studio 2010" instead of just
"Visual Studio 10". This is correct except that for the Express edition
we need "Visual C++ Express 2010".
For VS 11, since commit f0d66ab4 (VS11: Fix comment generated at the top
of *.sln files, 2011-10-20) we use "Visual Studio 11" in the .sln header
but the preferred value is "Visual Studio 2012" (just as the first
commit mentioned above fixed for VS 10). Also for the Express edition
we need "Visual Studio Express 2012 for Windows Desktop".
The API for retrieving per-config COMPILE_DEFINITIONS has long
existed because of the COMPILE_DEFINITIONS_<CONFIG> style
properties. Ensure that the provided configuration being generated
is also used to evaluate the generator expressions
in cmTarget::GetCompileDefinitions.
Both the generic COMPILE_DEFINITIONS and the config-specific
variant need to be evaluated with the requested configuration. This
has the side-effect that the COMPILE_DEFINITIONS does not need to
be additionally evaluated with no configuration, so the callers can
be cleaned up a bit too.
Extract upstream KWSys using the following shell commands.
$ git archive --prefix=upstream-kwsys/ 2d263bc3 | tar x
$ git shortlog --no-merges --abbrev=8 --format='%h %s' 5c34ed2e..2d263bc3
Paul Kunysch (1):
2d263bc3 Process: Increase FD_SETSIZE on Cygwin
Sean McBride (1):
13f5badd SystemInformation: Replace __GNUG__ with __GNUC__
Change-Id: I2d29f6d7e9bbc34f7a9b40394a7ee05f3c537396
In some languages the compiler may need to know the path of the final
target file for which an object is being compiled. Honor the <TARGET>
placeholder for compilation rules to support such cases.
Note that this cannot work with OBJECT library targets because the final
target path is not known during compilation (there can even be more than
one final target).
Suggested-by: Vittorio Giovara <vittorio.giovara@gmail.com>
The commit d2536579 (Automoc: fix regression #13667, broken build in
phonon, 2012-11-19) changed Automoc to try to re-add the Qt header dir
if it was stripped out as an implicit include from the moc command
line. When invoking a compiler, those directories are stripped out
because they are built-in, but for moc, there are no built-in directories.
The follow-up commit acc22400 (Automoc: get include dirs without
stripping implicit include dirs off, 2012-12-07) went further by not
removing the implicit include dirs, if they were specified specifically
by the user.
This had the remaining problem that the implicit include dirs appeared
in a different order of precedence for moc compared to the compiler.
Resolve that by stripping out the include dirs, where specified for
the moc command line to, and then appending them at the end. Note that
the order of the appended implicit include directories is the order
they are specified in the CMAKE_CXX_IMPLICIT_INCLUDE_DIRECTORIES, not
the order specified by the user.
Rename the variable added by commit 9ce1b9ef (Add
CMAKE_BUILD_INTERFACE_INCLUDES build-variable, 2012-11-25) to
CMAKE_INCLUDE_CURRENT_DIR_IN_INTERFACE to be more consistent with the
existing CMAKE_INCLUDE_CURRENT_DIR variable.
Suggested-by: Alex Neundorf <neundorf@kde.org>
If there is a Qt 5.0.3 release, it may or may not contain the patch
that fixes this issue.
http://thread.gmane.org/gmane.comp.lib.qt.releasing/882
Just use the workaround until 5.1.0 which certainly will contain the
fix. Don't use the workaround before Qt 5.0.0.
We can't find both preprocessing expressions at once, because then
the BUILD_INTERFACE will always be favored if both are present, even
if INSTALL_INTERFACE appears first.
This was affecting the behavior of install(EXPORT) because the
INTERFACE_INCLUDE_DIRECTORIES contained entries like
/foo/include;$<INSTALL_INTERFACE:/bar/include>
As the INSTALL_INTERFACE always evaluates to '0', it always needs
to be preprocessed properly.
Petr Kmoch
Brad King
Stephen Kelly
Bill Hoffman
Kitware Robot
Paul Kunysch
Rex Dieter
Rolf Eike Beer