| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Disallow the use of config-specific source files with
the Visual Studio and Xcode generators. They don't have
any way to represent the condition currently.
Use the same common-config API in cmQtAutoGenerators. While
it accepts config-specific files, it doesn't have to support
multiple configurations yet.
Loop over the configs in cmTargetTraceDependencies
and cmGlobalGenerator::WriteSummary and consume all source
files.
Loop over the configs in cmComputeTargetDepends and compute the
object library dependencies for each config.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When config-specifig generator expressions are supported, a target
may have SOURCES:
src1.cpp $<$<CONFIG:Debug>:src2.cpp> $<$<CONFIG:Release>:src3.cpp>
and computation in cmTargetTraceDependencies would add each of the
src2.cpp and src3.cpp sources back to the target without a
config-guard. That would make the sources be used later when
generating the buildsystem, regardless of the configuration.
Avoid calling AddSource on the target with the result of the
GetSourceFiles call.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
If CMAKE_BUILD_TYPE is set, and user code contains:
target_link_libraries(myexe prefix_$<$<CONFIG:Debug>:debug>)
then the computation with an empty config was computing a target-level
dependency on a target or library called prefix_, and a dependency
on a target or library called prefix_debug (as expected).
The existing logic skips 'prefix_' because it is not a known target,
and defers to the link-dependencies logic to find the library. The
link-dependencies logic does not incorrectly handle the config as
cmComputeTargetDepends did, and so did not encounter 'prefix_'
during its computation. This likely had no effect on the generated
buildsystem.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Add a ComputeObjectMapping method to compute the object
names. It takes mapping to populate as an out-parameter so
that it can be extended in the future with parameters
relevant to generator expression evaluation.
Remove the supporting cmGeneratorTarget::AddObject method. It is
no longer needed as the container member is populated directly.
The ComputeObjectMapping method is called whenever objects are
requested from the cmGeneratorTarget. Because the Xcode generator
makes no such request, explicitly invoke the method from that
generator so that the logic of checking for bad sources in object
libraries is executed.
In a follow-up, the UseObjectLibraries usage may be replaced by a
true generator expression evaluator for TARGET_OBJECTS. That
will require generators to use cmGeneratorTarget::GetExternalObjects
which is not currently the case for Xcode and VS generators.
|
| |
|
|
|
|
|
|
|
| |
Remove up-front object library computation from cmGlobalGenerator.
Adjust tests for message coming from the generator expression
evaluation.
|
|
|
|
| |
Relieve cmGeneratorTarget of that responsibility.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Remove use of UseObjectLibraries from Makefile and Ninja generators. It
is not needed now because those generators use GetExternalObjects
which already contains the objects from object libraries.
The VS10 generator calls both the UseObjectLibraries and the GetExternalObjects
methods. Ensure that duplicates are not created by skipping objects
from object libraries in handling of GetExternalObjects.
Similarly, fix VS6, VS7 and Xcode object handling by skipping
external objects from OBJECT_LIBRARY usage as appropriate.
The error message in the BadSourceExpression1 test is now reported
by the generator expression evaluator, so it has different text.
|
|
|
|
| |
Add policy CMP0051 to control this behavior.
|
|
|
|
|
| |
Avoid calling it too early when cmGeneratorTarget instances don't
yet exist.
|
|
|
|
| |
Strip out any generator expressions in the input string.
|
| |
|
|
|
|
|
|
|
| |
This will allow the strings to contain generator expressions.
At this point, generator expressions are still not part of the
SOURCES property when it is read.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Otherwise Matches() ends up doing a comparison of
the directories
/path/to/dir/subdir/..
and
/path/to/dir
as strings and not matching where it should.
|
|
|
|
|
| |
The string overload is never called. This allows the removal of
the unused UpdateDirectory method.
|
|
|
|
| |
It is no longer used.
|
|
|
|
|
| |
Continue to call GetOrCreateSource where necessary to create
cmSourceFile objects which have the GENERATED attribute set.
|
| |
|
|
|
|
| |
This allows using it in containers and algorithms.
|
|
|
|
| |
Add a new AddSource method for future use.
|
| |
|
|
|
|
| |
Ensure it is populated before tracing dependencies.
|
| |
|
| |
|
| |
|
| |
|
|\
| |
| |
| |
| | |
90e22f8f OS X: Fix Info.plist placement in a CFBundle
|
| |
| |
| |
| |
| |
| |
| | |
Fix cmOSXBundleGenerator::CreateCFBundle to place Info.plist under the
same root directory as the rest of the bundle. Without this, Info.plist
was placed into CMAKE_BINARY_DIR, not CMAKE_CURRENT_BINARY_DIR because
the target path was not generated correctly.
|
| | |
|
|\ \
| | |
| | |
| | |
| | |
| | | |
71a11252 QtAutogen: Fix use of multiple ui files in a single target.
261acd91 QtAutogen: Use the basename for resource files.
|
| | |
| | |
| | |
| | |
| | |
| | | |
Don't store a mapping of the directory to the ui file. The directory
will be a unique key, allowing only one ui file to be specified.
Use the source file name instead as the mapping key.
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
The rcc tool generates a cpp file with a symbol called qInitResources
or called qInitResources_${name}, if the name is passed. The
qInitResources symbol clashes if multiple qrc files are used in
one target.
Always pass the name to ensure that the symbol is unique. This is also
the behavior of the qtx_add_resource macros.
|
| |\ \ |
|
|\ \ \ \
| | | | |
| | | | |
| | | | |
| | | | | |
9523d2a5 ninja: Add support for custom depfile formats
|
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Not everything that isn't MSVC is GCC. I have support for LDC's depfile
format on its way upstream[1], but its future is uncertain. CMake should
at least support this for future depfile formats.
[1]https://github.com/martine/ninja/pull/721
|
|\ \ \ \ \
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
bccc056b cmake: Advise user to remove CMakeFiles with CMakeCache.txt (#14820)
|
| | | | | | |
|
|\ \ \ \ \ \
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
0cc42b87 Haiku: Fix compiler detection when using distcc
84603d80 Haiku: Enable CMake builtin ELF editor
|
| |/ / / / /
| | | | | |
| | | | | |
| | | | | | |
Co-Author: Brad King <brad.king@kitware.com>
|
|\ \ \ \ \ \
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
f1fd3714 cmMakefile: Report type of INTERFACE library in conflict.
|
| |/ / / / / |
|
|\ \ \ \ \ \
| |_|_|_|_|/
|/| | | | |
| | | | | |
| | | | | |
| | | | | | |
ed6ddb89 Merge branch 'upstream-kwsys' into update-kwsys
12faf00d KWSys 2014-03-19 (a8aa1014)
|
| |/ / / / |
|
| | | | | |
|
| | | | | |
|
| |/ / /
|/| | | |
|
| | | | |
|
| | | | |
|
|/ / / |
|
|\ \ \
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
64c2342a Watcom: Enable 'WMake Makefiles' generator on Linux
5d9aa66c Watcom: Introduce OpenWatcom compiler id and fix compiler version
9292d3b8 Watcom: Detect compiler target architecture and platform
fbc883c9 Watcom: Add one blank line to Makefile for better readability
|