| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
| |
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.
|
|\
| |
| |
| |
| |
| |
| | |
62b4df1e84 Help: Mention IMPORTED_OBJECTS in add_library docs
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !2216
|
| |
| |
| |
| |
| |
| |
| | |
The `IMPORTED_OBJECTS` is to object libraries as `IMPORTED_LOCATION`
is to normal libraries.
Fixes: #18176
|
|/ |
|
|
|
|
|
| |
Inspired-by: Deniz Bahadir <dbahadir@benocs.com>
Issue: #14778
|
|
|
|
|
|
|
| |
The docs mentioned that it happened, but not when. Mention Xcode since
it is the culprit today.
See #16524.
|
|
|
|
|
| |
Issue: #15569
Issue: #17197
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The `add_library` and `add_executable` commands can now be called with
no source-files and won't generate a warning or error message, as long
as source-files will be added later via the `target_sources` command.
If during the generation step still no sources are associated with
targets created by such calls a useful error message will be generated
and generation fails.
Targets of type `INTERFACE_LIBRARY`, `UTILITY` or `GLOBAL_TARGET` are
excluded from this check because we do not need sources for these target
types during generation.
Fixes: #16872
|
| |
|
|
|
|
| |
Describe how to get sources into IDE project files.
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
| |
The Debian package checker tool (lintian) detected several typos in
CMake.
|
|
|
|
|
|
|
| |
CMake assumes that a SHARED library compiled on Windows will export a LIB file.
This is not actually the case on Visual C++ if the library does not export any
symbols, and causes incremental builds to break if the user specifies SHARED
anyway. (Users should use MODULE libraries instead.)
|
| |
|
|\
| |
| |
| |
| | |
Resolve conflict in Modules/ExternalProject.cmake by keeping our side,
which is more completely revised.
|
| |
| |
| |
| | |
Use a bullet list to make it easier to read.
|
|/ |
|
|
|
|
|
|
|
|
|
|
|
| |
Loosen this restriction on OBJECT libraries to allow source files of any
name to be generated by custom commands or listed for reference in IDE
projects so long as they would not affect linking of a normal library.
Update the rejection message to be more specific about the looser
restriction.
Extend the ObjectLibrary test to cover a ".cmake" file generated by a
custom command in an OBJECT library.
|
| |
|
|
|
|
|
| |
Add a section for each library type signature. Add a table of contents
at the top for the html builder.
|
|
|
|
|
|
|
| |
The add_library(INTERFACE) and Interface Libraries documentation
list all the INTERFACE_* properties and target_* commands that
can be used to define the interface. Add INTERFACE_SOURCES
and target_sources() to these lists for completeness.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
| |
Cross-link to the cmake-buildsystem manual.
|
|
|
|
|
| |
Document the valid signatures. Add a test for the IMPORTED GLOBAL
signature.
|
| |
|
|
Run the convert-help.bash script to convert documentation:
./convert-help.bash "/path/to/CMake-build/bin"
Then remove it.
|