| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
| |
Since commit 4391913133 (Add INTERFACE libraries to generated
buildsystem if they have SOURCES, 2020-07-20, v3.19.0-rc1~346^2~1), the
VS generator may process INTERFACE libraries. Avoid code paths in the
generator that process include directories because they should not be
used by INTERFACE libraries since they do not compile anything.
Fixes: #22494
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
INTERFACE libraries were created with the intention of collecting usage
requirements for use by other targets via `target_link_libraries`.
Therefore they were not allowed to have SOURCES and were not included in
the generated buildsystem. In practice, this has become limiting:
* Header-only libraries do have sources, they just do not compile.
Developers should be able to edit those sources (the header files)
in their IDE.
* Header-only libraries may need to generate some of their header
files via custom commands.
Some projects work around these limitations by pairing each interface
library with an `add_custom_target` that makes the header files and
custom commands appear in the generated buildsystem and in IDEs.
Lift such limitations by allowing INTERFACE libraries to have SOURCES.
For those with sources, add a corresponding build target to the
generated buildsystem.
Fixes: #19145
|
| |
|
|
|
|
|
|
|
|
|
| |
Previously we disallowed use of arbitrary properties on INTERFACE
libraries. The goal was to future-proof projects using them by not
allowing properties to be set that may affect their future inclusion in
the generated buildsystem. In order to prepare to actually include
INTERFACE libraries in the generated buildsystem, drop the filter and
allow arbitrary properties to be set.
Issue: #19145
|
|
|
Our RunCMake.<lower-case> namespace is meant for testing individual
CMake language commands.
|
