d96e5d9a Tests: use BYPRODUCTS in the CustomCommandWorkingDirectory test
664591ce RunCMake.Ninja: add a test for assumed sources
adf60b28 ninja: break unnecessary target dependencies
01c5bb95 RunCMake.Ninja: support passing arguments when running ninja
7f947b60 ninja: remove duplicate order-only dependencies
e9827eba ninja: describe the intermediate order depends target better
b57b7d8e Ninja: Order Fortran dyndep file generation explicitly
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !430
This was inadvertently testing the assumed sources behavior in Ninja (no
other test seems to exercise it). There is now a test explicitly testing
it in `RunCMake.Ninja`, so fix this test to work properly regardless of
the assumed sources behavior.
Previously, given two libraries, X and Y where X depends on Y, all
object compilations of X would require the Y library to have been linked
before being compiled. This is not necessary and can instead be loosened
such that object compilations of X only depend on the order-only
dependencies of Y to be completed. This is to ensure that generated
sources, headers, custom commands, etc. are completed before X starts to
compile its objects.
This should help build performance in projects with many libraries which
cause a deep library dependency chain. Previously, a library at the
bottom would not start compilation until after all other libraries
completed, but now only its link step needs to wait and its compilation
jobs can be run in parallel with other tasks.
Fixes: #15555
eec93bce Allow OBJECT libraries to be installed, exported, and imported
93c89bc7 Genex: Allow TARGET_OBJECTS to be used everywhere
ac0cf7ff Genex: Reject TARGET_OBJECTS on non-object libraries earlier
8577978c Tests: ExportImport C code should use explicit (void) in prototypes
26cfd039 cmInstallTargetGenerator: Re-order GenerateScriptForConfig logic
25f3f22a cmGlobalGenerator: Add method to check if object file location is known
d596c550 cmGeneratorTarget: Add method to get the object file directory
930042f2 cmGeneratorTarget: Factor out a GetTargetObjectNames method
...
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !712
Drop hard-coded paths from this test. If we later need machine-specific
environment entries we can add dedicated infrastructure for it to be
configured locally.
Since `cmake --help` output now uses `[arch]` placeholders for the VS
generators, this test has been extracting invalid generator names.
Switch to using `cmake -E capabilities` to get a more robust listing of
the generators that does not depend on parsing human-readable help
output.
Teach install() and export() to handle the actual object files.
Disallow this on Xcode with multiple architectures because it
still cannot be cleanly supported there.
Co-Author: Brad King <brad.king@kitware.com>
Previously the `TARGET_OBJECTS` generator expression was limited
only to use in a buildsystem context so that Xcode's placeholders
in object file paths can be evaluated. Lift this restriction so
that the expression can at least be used in most settings.
Co-Author: Brad King <brad.king@kitware.com>
Move the diagnostic that rejects the TARGET_OBJECTS generator expression
in non-buildsystem context until after the check for whether the named
target is an object library. This order will makes more sense than the
previous order once TARGET_OBJECTS is allowed in non-buildsystem
context.
Refactoring in commit 60307c5056 (cmGeneratorTarget: Replace source
classifier implementation, 2017-04-07) accidentally regressed support
for CMP0026's OLD behavior in the case of a source file written by
project code during the configure step after getting a LOCATION. We
should not perform full source classification until the generate step
because files written by the project's configure step may not exist yet.
Add special logic to support this case. Add a test case for it.
Reported-by: David Stoup <david.stoup@kitware.com>
Add a `FILES_FROM_DIR` option to install a specific set of files
specified relative to a given directory and preserve their layout
in the destination. Currently we intend to use this internally
to implement other things so we don't provide an `install()`
porcelain or documentation yet.
It is quite often the project description has used in a real world software.
Examples include:
* part of a help screen of the application
* builtin resources (`*.rc` files, data for "About" dialog of a GUI app, & etc)
* most generators for CPack can use it
* it could be used by documentary software (Doxygen, Sphinx) which is usually
integrated to CMake based projects via `add_custom_target()`
Now `project()` call learned an optional `DESCRIPTION` parameter with a
short string describing a project. Being specified, it would set the
`PROJECT_DESCRIPTION` variable which could be used in `configure_file()`
or whatever user wants. Also `PROJECT_DESCRIPTION` is a default value
for `CPACK_PACKAGE_DESCRIPTION_SUMMARY`.
Some machines have incomplete or otherwise broken installations of
specific packages. Allow local configuration to prevent the test from
failing on such packages if the version number cannot be extracted.
The `ld` tool in Xcode 8.3 now has a `-lto_library <path>` flag. Ignore
the flag instead of accidentally parsing it as `-l` with `to_library`.
Fixes: #16766
Since commit v2.8.11~239^2~1 (ProcessorCount test: fix path to
cmsysTestsCxx executable, 2013-01-24) we accidentally printed a literal
`${CTEST_CONFIGURATION_TYPE}` instead of the actual build configuration.
Update the message to use a generator expression to get the real build
configuration used.
Brad King