Refactoring in commit a2514f15 (Simplify cmNinjaTargetGenerator using
cmGeneratorTarget, 2012-03-13) accidentally removed mapping of .def file
paths through ConvertToNinjaPath (via GetSourceFilePath). Take the
ModuleDefinitionFile value from cmGeneratorTarget and map it correctly
through ConvertToNinjaPath.
In addition to generating cleaner paths in the ninja build files this
correctly links up references to a generated .def file with the custom
command output that produces it.
Since commit 328c0f65 (Simplify cmVisualStudio10TargetGenerator source
classification, 2012-03-19) the VS 10 generator uses the
cmGeneratorTarget source classification instead of directly getting the
list of source files from the target. This accidentally dropped the
CMakeLists.txt files from generated projects because they are added too
late for cmGeneratorTarget.
All generator-specific source files must be added to targets prior to
cmGeneratorTarget construction. Refactor addition of the CMakeLists.txt
files with CMake re-run custom commands to take place before normal
generation begins, and therefore early enough to be included in the
cmGeneratorTarget classification.
Commit 328c0f65 (Simplify cmVisualStudio10TargetGenerator source
classification, 2012-03-19) introduced the first use of source
classification from cmGeneratorTarget (which originated as Makefile
generator logic) in a Visual Studio generator for handling of header
files. Fix classification of header files to match known header
extensions instead of only the HEADER_FILE_ONLY property. Make it
consistent with the "Header Files" source group.
Refactoring by commit 11d9b211 (Add cmGeneratorTarget to represent a
target during generation, 2012-03-07) and commit 45c2f932 (Simplify
cmMakefileTargetGenerator using cmGeneratorTarget, 2012-03-07) preserved
behavior introduced by commit 7740ccd1 (some cleanup of the makefile
generator, 2006-02-14) that favored the IgnoreFile extension test over
the availability of a known compilation language associated with a
source file. If a source is not marked as HEADER_FILE_ONLY and has a
known language extension or an explicit LANGUAGE property it should be
treated as that language. The LANGUAGE source file property
documentation says so.
Starting with Python3, standard Python installs may have additional ABI
flags attached to include directories and library names. As of 3.2, the
following flags are in the configure file:
d -> --with-debug
m -> --with-pymalloc
u -> --with-wide-unicode
Python 3.3 seems to no longer have --with-wide-unicode. Hopefully Python
will ensure that the possible flags always show up in a stable order.
The 'd' flag is ignored since the debug library is considered separate.
There is still the problem where ABI flags cannot be specified in
find_package since the letters confuse the version comparator.
If PYTHON_INCLUDE_PATH is put into the cache, then it will always
override whatever might be found and PYTHON_INCLUDE_DIR is never given a
chance to find something different. It being marked as INTERNAL also
means that it cannot be changed without editing CMakeCache.txt directly.
Basically, the scenario is that if the Python version is changed, then
deleting PYTHON_INCLUDE_DIR doesn't work because any cached
PYTHON_INCLUDE_PATH variable is set before find_path is even called. Any
build tree using a previous version will still need either manual
removal of PYTHON_INCLUDE_PATH or a complete reconfigure, but in the
future changing the Python version can be accomplished by deleting
PYTHON_INCLUDE_DIR and reconfiguring with the new version.
9b32475 automoc: add define to test which caused bug #130182066511 automoc: fix#13018, proper cmake escaping to avoid false rebuilds
c652812 make cmLocalGenerator::EscapeForCMake() static
This does not really test that the bug is fixed, but at least it makes
it easy to check manually whether the bug is there or not.
I have to see whether I can build a test which does test that
a target is not rebuilt everytime.
Alex
The variables stored in the AutomocInfo.cmake file were not properly
escaped, so when reading them back they could turn into lists, if they
contained double quotes initially.
This patch fixes this by using cmLocalGenerator::EscapeForCMake() to
escape the variables properly.
Alex
Since commit 4693cf84 (Xcode: Detect new default locations of Xcode 4.3
bits and pieces) Darwin.cmake detects the developer application
directory instead of hard-coding /Developer. Replace the hard-coded
path in CMAKE_SYSTEM_APPBUNDLE_PATH using the computed result.
Patch by Amine Khaldi!
Also, start using the -MT flag to set a target name for depfiles.
This works around a bug observed in distcc, as explained in the
comment. Based on a patch by Alexander Usov.
Use "file:///..." instead of "file:////..." when the file system path
starts in a slash. Commit 0916cc88 (CTest.UpdateHG: Fix repo URL for
local filesystem, 2012-03-02) added a third slash after "file://"
unconditionally. This worked for many file systems but not on Cygwin
where "file:////cygdrive/..." looks like "file://" followed by a network
file path "//cygdrive/...". Add the slash only if the file system path
does not already start with one.
This patch uses get_filename_component(REALPATH) so symlinks in the path
to Eclipse are resolved, which makes the version detection work in such cases.
Alex
Our only expectation of version number variables should be that
they begin with a decimal digit for VERSION_LESS, VERSION_EQUAL
and VERSION_GREATER comparison purposes. If people put extra
blah blah after a version number like "1.2.3 (this is some super
special extra information about our funky proprietary build of
the official 1.2.3 release)" then we should be ok with that.
So: now we have the following expectations for version number
variable content for the purposes of the AllFindModules test:
- it should start with a decimal digit (match "^[0-9]")
- it should not be empty
- it should not be VERSION_EQUAL 0
- it should not be NOT VERSION_GREATER 0