| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The add_external_project function separates its arguments with ';'
separators, so previously no command line argument could contain one.
When specifying CMAKE_ARGS, some -D argument values may need to contain
a semicolon to form lists in the external project cache.
This adds add_external_project argument LIST_SEPARATOR to specify a list
separator string. The separator is replaced by ';' in arguments to any
command created to drive the external project. For example:
add_external_project(...
LIST_SEPARATOR ::
CMAKE_ARGS -DSOME_LIST:STRING=A::B::C
...)
passes "-DSOME_LIST:STRING=A;B;C" to CMake for the external project.
|
| |
|
|
|
|
| |
This fixes the get_configure_command_id function to not mistake
CONFIGURE_COMMAND values that run "cmake -P" or "cmake -E" for a CMake
project configuration. These values just help run scripts.
|
| |
|
|
| |
This simplifies the implementation with add_external_project_step.
|
| |
|
|
| |
This simplifies the implementation with add_external_project_step.
|
| |
|
|
| |
This simplifies the implementation with add_external_project_step.
|
| |
|
|
| |
This simplifies the implementation with add_external_project_step.
|
| |
|
|
| |
This simplifies the implementation with add_external_project_step.
|
| |
|
|
| |
This simplifies the implementation with add_external_project_step.
|
| |
|
|
|
|
| |
This creates function 'add_external_project_step' to centralize creation
of external project steps. Users may call it to add custom steps to
external project builds.
|
| |
|
|
|
|
| |
The add_external_project function parses its arguments and puts them in
properties of the target it creates. This factors out implementation of
the behavior for use by other functions in the module.
|
| |
|
|
|
| |
This separates creation of the project completion sentinel file from the
'install' step to allow more steps to be added in between later.
|
| | |
|
| |
|
|
|
|
| |
The patch step runs parallel to the update step since it does not make
sense to have both. Configuration of the step requires specification of
a PATCH_COMMAND argument to add_external_project.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This rewrites the keyword/argument parsing and handling in the
AddExternalProject module to use arguments more literally:
- The strict keyword-value pairing is gone in favor of keywords with
arbitrary non-keyword values. This avoids requiring users to escape
spaces and quotes in command lines.
- Customized step command lines are now specified with a single
keyword <step>_COMMAND instead of putting the arguments in a
separate entry (previously called <step>_ARGS).
- Build step custom commands now use VERBATIM mode so that arguments
are correctly escaped on the command line during builds.
|
| |
|
|
|
|
|
| |
This teaches AddExternalProject to run "$(MAKE)" for build and install
steps of CMake-based external projects when using a Makefile generator.
It allows the external project to participate in a parallel make invoked
on the superproject.
|
| |
|
|
|
|
| |
This uses the get_property command to simplify property lookup in the
AddExternalProject module. It distinguishes for build and install
argument properties the cases of unset and set to empty.
|
| |
|
|
| |
it properly by using the SYMBOLIC source file property to indicate to WMake when the sentinel file is not actually written by the update step.
|
| |
|
|
| |
UPDATE_COMMAND handling. Output a -complete sentinel in synch with the -install sentinel, but do not list it as an OUTPUT of the custom command. That breaks the chaining of add_custom_commands between custom targets, but allows for a file-level dependency expression that will cause proper incremental rebuilds. When earlier targets rebuild, subsequent dependent targets will also rebuild. CVS and SVN update commands are always out-of-date so that they always run to get the latest source. To suppress that behavior on a per-external project basis use an explicit empty string for UPDATE_COMMAND. The source will still be checked out from the repository prior to the update step by the download step.
|
| |
|
|
| |
installing. If none specified default to the cmake used to configure the outer/aggregating project.
|
| |
|
|
| |
configure time as well as having custom commands that create them. Necessary for the Borland Makefiles generator to generate short path names in the makefile build rules. Also, make sure all custom commands chain together properly through the use of the sentinel files.
|
| |
|
|
| |
for an external project. Add capability of customizing the download step. Add tests of empty projects. Better comments and error checking in AddExternalProject.cmake. In tests, use KWStyle from CVSHEAD to see if QNX continuous can build the latest KWStyle. Make KWStyle test depend on all previous test external projects so it builds last to catch other issues before any KWStyle compile errors.
|
|
|
fixing, more tests and documentation certain to follow as it gets used by others...
|
