| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
| |
The policy plays an important role in the behavior of the `install()`
command, so the latter's documentation should mention it.
|
|
|
|
| |
Encourage people to use cmake(1) --install instead.
|
|
|
|
| |
Fixes: #20427
|
| |
|
|
|
|
|
| |
Advise against absolute DESTINATIONs as they are not supported
by CPack installer generators.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
On AIX, plugins meant to be loaded into executables via `dlopen` must be
linked with access to a list of symbols exported from the executable in
order to use them (when not using runtime linking). The AIX linker
supports specifying this list as an "import file" passed on the command
line either via the `-bI:...` option or (with a leading `#! .` line) as
a normal input file like any other library file.
The linker import file plays the same role on AIX as import libraries do
on Windows. Teach CMake to enable its import library abstraction on AIX
for executables with the `ENABLE_EXPORTS` target property set. Teach
our internal `ExportImportList` script to optionally generate a leading
`#! .` line at the top of the generated export/import list. Update our
rule for linking an executable with exports to generate a public-facing
"import library" implemented as an AIX linker import file.
With this approach, our existing infrastructure for handling import
libraries on Windows will now work for AIX linker import files too:
* Plugins that link to their executable's symbols will be automatically
linked using the import file on the command line.
* The executable's import file will be (optionally) installed and
exported for use in linking externally-built plugins.
This will allow executables and their plugins to build even if we later
turn off runtime linking.
Issue: #19163
|
| |
|
|
|
|
|
|
|
| |
Also support installing headers on an INTERFACE library.
Signed-off-by: Avraham Shukron <avraham.shukron@gmail.com>
Fixes: #15234
|
|\
| |
| |
| |
| |
| |
| | |
a5f79b83c7 Help: clarify DESTINATION and TYPE usage for install()
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !3052
|
| | |
|
| | |
|
| | |
|
|/ |
|
|
|
|
|
|
|
| |
This also introduces CMP0087 which will keep the OLD behaviour of not
evaluating generator expressions
Fixes: #15785
|
|
|
|
|
| |
This change adds documentation for the new DESTINATION behavior of
the install() command.
|
|
|
|
|
|
| |
* Replace most "::" by ".. code-block:: cmake"
* Header sentence in imperative voice,
detailed command description in present tense.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Revert commit v3.13.0-rc1~441^2 (install: Teach CODE,SCRIPT modes to
evaluate generator expressions, 2018-05-29). Unfortunately it has
been found to break existing code in a real project, e.g.
install(CODE [[
message("$<FOOBAR>")
]])
Address this regression by reverting support for the 3.13 release
series. Support can be restored later with a policy for compatibility.
Issue: #15785
Fixes: #18435
|
| |
|
|
|
|
|
|
|
|
| |
Apple's main Operating system changed their name from OS X to macOS:
https://www.engadget.com/2016/06/13/os-x-is-now-macos/
Revise documentation accordingly.
|
|
|
|
|
|
|
|
| |
Previously, `install(TARGETS)` would only accept targets created in the same
directory scope. Relax this restriction by searching the global scope when
determining whether or not a target exists.
Fixes: #14444
|
|
|
|
| |
Fixes: #15785
|
|
|
|
|
|
|
|
|
| |
Summarize the command signatures in one block at the top of the
documentation as is typical in Unix command-line tool manuals.
Make the mode keywords links to the corresponding full signature
and documentation.
Issue: #17948
|
|
|
|
|
|
|
| |
The "undefined behavior" that the install(EXPORT) command warned about
was simply the possibility of build errors (or other errors) if the
referenced targets aren't installed. As long as the referenced targets
are installed, this won't be an issue.
|
|
|
|
|
|
|
| |
For shared libraries, this allows you to specify separate components
for the shared library and for the namelink.
Suggested in https://cmake.org/pipermail/cmake-developers/2014-December/024032.html.
|
|
|
|
|
|
| |
The documentation for install(TARGETS) has been rearranged so that
the options are presented as a list, for better readability and
maintenance.
|
| |
|
|
|
|
|
|
| |
This file, which is currently undocumented, is useful for external
packaging programs that wish to install only a single component at a
time. This change adds documentation for the file.
|
|
|
|
|
|
|
|
|
|
| |
`install(EXPORT_ANDROID_MK)` is its own mode, not an option to the
normal `install(EXPORT)` mode.
While at it, also fix the prose in our documented example to match
the code.
Fixes: #17891
|
|
|
|
|
| |
Inspired-by: Deniz Bahadir <dbahadir@benocs.com>
Issue: #14778
|
|
|
|
|
|
|
|
|
|
|
| |
Teach the `install` and `export` commands to support installing and
exporting `OBJECT` libraries without their object files. Transform
them to `INTERFACE` libraries in such cases.
For `install(TARGETS)`, activate this when no destination for the object
files is specified. For `export`, activate this only under Xcode with
multiple architectures when we have no well-defined object file
locations to give to clients.
|
|
|
|
| |
Fixes #16362.
|
|
|
|
| |
Some are user-facing. Others are source comments.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Some are user facing.
Found using
codespell -q 3 --skip="./Utilities" -I .cmake-whitelist.txt`
whereby the whitelist contained:
ans
dum
helpfull
emmited
emmitted
buil
iff
isnt
nto
ot
pathes
substract
te
todays
upto
whitespaces
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
| |
Closes: #16432
|
|
|
|
|
|
|
|
|
|
|
| |
Add options to the `install()` and `export()` commands to export the
targets we build into Android.mk files that reference them as prebuilt
libraries with associated usage requirements (compile definitions,
include directories, link libraries). This will allow CMake-built
projects to be imported into projects using the Android NDK build
system.
Closes: #15562
|
|
|
|
|
|
|
|
| |
The option does not actually participate in argument groups like the
others because it does not actually install anything. Fix the order
in the documentation accordingly.
Reported-by: Daniel Wirtz <daniel.wirtz@simtech.uni-stuttgart.de>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Let us take an example of a project that has some tests in a component
that need to be installed into a dedicated test package. The user
expectation is that the result could be achieved by typing the
following:
make
make tests
make install
DESTDIR=/testpkgs make install-tests
However this results in test components in the default installation as
well as the testpkg.
Add an EXCLUDE_FROM_ALL option to the install() command to tell it that
the installation rule should not be included unless its component is
explicitly specified for installation.
|
|
|
|
|
| |
Teach install(DIRECTORY) to support generator expressions in the list
of directories, much like install(FILES) already supports.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
This will allow per-config destinations for targets in EXPORT sets.
Using multiple install(TARGETS) with separate CONFIGURATIONS is
rejected as a target appearing more than once in an export set.
Now instead one can write
install(TARGETS foo EXPORT exp DESTINATION lib/$<CONFIG>)
to get a single logical membership of the target in the export set
while still having a per-config destination.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Installing large directories, e.g., the output of a doxygen run, prints
one line per file resulting in too much noise in the build output. Add
an option to the install(DIRECTORY) command to not print anything upon
make install.
Extend the RunCMake.install test with cases covering MESSAGE_NEVER
behavior of the install(DIRECTORY) command.
Suggested-by: Stefan Eilemann <Stefan.Eilemann@epfl.ch>
|
|
|
|
|
|
|
|
|
| |
Create a variable to allow users to control which installation
messages are printed. In particular, provide a "LAZY" setting
that prints "Installing" messages but not "Up-to-date" messages.
This is desirable for incremental re-installations.
Suggested-by: J Decker <d3ck0r@gmail.com>
|
|
|
|
|
| |
Use section headers instead of horizontal dividers so that one may link
to the sections.
|
|
|
|
|
|
|
|
| |
Teach the install(FILES) and install(PROGRAMS) commands to evaluate
generator expressions in the list of files.
Extend the ExportImport test to cover installation cases involving
generator expressions.
|
|
|
|
| |
Add inline markup and explicit markup blocks as appropriate.
|
| |
|
|
Run the convert-help.bash script to convert documentation:
./convert-help.bash "/path/to/CMake-build/bin"
Then remove it.
|