The <OBJECT_DIR> placeholder is supposed to be the base intermediate
files directory for the current target. This is how it gets replaced
during link line generation. However, during compile line generation
we replace it with the directory containing the current object file
which may be a subdirectory. Fix replacement of <OBJECT_DIR> in the
generated compile lines to be the base intermediate files directory.
This was expoxed by commit 42ba1b08 (VS: Separate compiler and linker
PDB files, 2013-04-05) when we added a "/Fd<OBJECT_DIR>/" flag to the
MSVC compile line in order to match the VS IDE default compiler program
database location in the intermediate files directory. For source files
in a subdirectory relative to the current target this caused the wrong
location to be used for the compiler program database. This becomes
particularly important when using precompiled headers.
While at it, use the cmTarget::GetSupportDirectory method to compute the
intermediate files directory for the current target instead of repeating
the logic in a few places.
With this patch, cmake now puts the MachO64 bit
binary file parser into the config file if the detected
Eclipse is at least Helios (7.0), otherwise with the old
parser executables will not be recognized by Eclipse.
Alex
With this patch, simply also the information used
by the build plugin in kate <= 4.12 is put into the
generated json file. The new build plugin (coming
in 4.13) simply ignores this (and vice versa).
Alex
Teach the export command to handle export sets defined by invocations
of install(TARGETS ... EXPORT foo). This makes maintenance of targets
exported to both the build tree and install tree trivial.
The first regression resulted in endless looping due to unrun test
dependencies. The second regression prioritized all tests with dependencies
in serial test runs.
Populate a separate vector of files and append them separately. This
was the pattern used prior to commit 035b6908 (Autogen: Split AutoRcc
handling into two methods, 2013-12-10), which was erroneously not
maintained in that refactoring.
The parent commit changed the AutogensType::value_type to be
"std::pair<cmQtAutoGenerators,cmTarget const*>" but our std::make_pair
call returns "std::pair<cmQtAutoGenerators,cmTarget*>". Construct the
value_type directly instead of using make_pair. Otherwise the Sun 5.9
compiler complains
".../Source/cmGlobalGenerator.cxx", line 1281: Error:
Formal argument x of type "const std::pair<cmQtAutoGenerators, const cmTarget*>&"
in call to "std::vector<std::pair<cmQtAutoGenerators, const cmTarget*> >
::push_back(const std::pair<cmQtAutoGenerators, const cmTarget*>&)" is being
passed "std::pair<cmQtAutoGenerators, cmTarget*>".
Add the .NOTPARALLEL target to each local Makefile command-line
interface entry point file so that even with -j we launch only
one "make -f Makefile2" at a time. The actual build rules
in Makefile2 and lower will still run in parallel.
Do not add .NOTPARALLEL for Borland or Watcom make tools because
they do not tolerate it. Other make tools that do not understand
.NOTPARALLEL will not be hurt.
Suggested-by: Robert Luberda <robert-cmake@debian.org>
The properties object has just been created, so is always empty,
which means the if block is never entered. The following lines do
not have any effect because an INTERFACE library has no LOCATION.
At the end, no code is generated for INTERFACE libraries in
config-specific exported files, so skip them early.
Existing single-parameter expressions work due to special casing
which assumes that if there is only one parameter, and the node
accepts arbitrary content, then the result is the input.
This is true for the existing expressions matching that
pattern - namely the "1" and "TARGET_NAME" expressions. However,
the LOWER_CASE, and UPPER_CASE expressions should also accept
arbitrary content, and in their case, the result is not the input.
Refactor the cmGeneratorExpressionEvaluator to allow that extension.
Actually evaluate the "1" and "0" nodes.
Added a new variable CPACK_WIX_PATCH_FILE that users can point at an
XML patch file. Fragments defined within the patch file will be inserted
at supported insertion points (currently Component, File and Directory).
As we're iterating over IMPORTED targets now, handle them in
the loop body. The existing behavior is harmless because generally
nothing is done anyway for IMPORTED targets in these code paths,
because they do not have sources for example.
Commit b04f3b9a (Create make rules for INTERFACE_LIBRARY
targets., 2013-08-21) extended the makefile generator to create
build targets for INTERFACE_LIBRARY targets. No other generators
were extended with this feature.
This conflicts with the feature of whitelisting of target properties
read from INTERFACE_LIBRARY targets. The INTERFACE_* properties
of the INTERFACE_LIBRARY may legitimately contain TARGET_PROPERTY
generator expressions for reading properties from the 'head target'.
The 'head target' would be the INTERFACE_LIBRARY itself when creating
the build rules for it, which means that non-whitelisted properties
would be read.
The INTERFACE_LIBRARY type does not have any LOCATION at all, so
return early from GetMappedConfig. GetMappedConfig is called from
two locations, one of which already pre-checks the INTERFACE_LIBRARY
case. Remove that pre-check and handle that case inside the method
instead.
77f3772 cmTarget: Require a compatible INTERFACE_AUTOUIC_OPTIONS from dependencies.
2e60b5f cmTarget: Report origin of COMPATIBLE_INTERFACE properties.
Revert the origin-tracking infrastructure from commit 98093c45 (QtAutoUic:
Add INTERFACE_AUTOUIC_OPTIONS target property., 2013-11-20). Use the
compatibility-tracking for compatible strings instead.
If two different dependencies require different AUTOUIC_OPTIONS,
cmake will now appropriately issue an error.
259bf09 Make the cmStrictTargetComparison operate on const cmTarget*.
8cc3cdb Help: Fix up the VISIBILITY_INLINES_HIDDEN docs.
1396ab8 Don't generate self-references for system include directories.
Since commit 5f5c92b9 (VS: Add internal APIs to find MSBuild,
devenv/VCExpress, and msdev, 2013-11-13) the VS generators have
known how to lookup the locations of their build tools directly.
Expose this information to CMake language code by defining new
variables to hold the paths to these tools.
Brad King
Clinton Stimpson
Kitware Robot
Alex Neundorf
Nils Gladitz
Stephen Kelly
David Golub