8a75c7ef Help: Document the export limitation of INTERFACE_SOURCES.
e1348056 Export: Disallow export of targets with INTERFACE_SOURCES
bb5905bb cmTarget: Don't allow relative paths in INTERFACE_SOURCES
808c77e2 Merge branch 'revert-cached-regex-clear' into revert-cached-regex-clear-for-master
7d674b5f Revert "ClearMatches: Only clear matches which were actually set" (#15261)
This can be allowed in the next release, but it needs to have some
features present and tested such as
* Ensuring that relative paths do not appear in the generated property.
* Ensuring that paths to the source or build directories do not appear.
* Generating a check in the file for CMake 3.1 or later so that the
resulting property will be consumed.
* Ensuring that any referenced targets are part of an export set and
generating a check for them.
* INSTALL_INTERFACE and BUILD_INTERFACE content.
All of these checks are already done for INTERFACE_INCLUDE_DIRECTORIES,
but it is too late to add them for INTERFACE_SOURCES for CMake 3.1.
As the checks introduce some new error conditions, it is better to
disallow exporting fully for this case and introduce proper error
conditions later instead of policies.
Follow the pattern of checks that are made for INTERFACE_INCLUDE_DIRECTORIES.
Existence is already checked by cmSourceFile::GetFullPath. Add a check
to disallow relative paths in source directories. Otherwise code such as
target_sources(lib1 INTERFACE foo.cpp)
would fail if consumed by a target in a different directory.
Unlike the INTERFACE_INCLUDE_DIRECTORIES behavior, we don't care whether
the entry comes from an IMPORTED target or not. In the include directories
case, the directory for a non-imported target might not exist yet but
might be created. In the sources case, a file which does not yet
exist in the filesystem must be explicitly marked with the GENERATED
property.
Adjust existing tests and add a new test for the error.
Since commit v3.1.0-rc1~688^2~15 (cmTarget: Add a method to obtain list of
filenames for sources, 2014-03-17) we have code paths that lookup sources by
strings containing their own full path after normalization to the actual case
on disk. This fails in the case that a cmSourceFile has already been created
with a different case in the filename. The comparison of the directory works
because it is always normalized. Only the comparison of the file name fails.
Fix this by using a case-insensitive comparison of source file names on
platforms that do not have case-sensitive filesystems.
Extract a new method to encapsulate the requirements of evaluating
dependent-expressions, namely, propagation of the
EvaluateForBuildsystem setting, which is missing from the
getLinkedTargetsContent implementation.
Commit v3.1.0-rc1~688^2 (Genex: Only evaluate TARGET_OBJECTS to determine
target sources., 2014-03-20) introduced an error case for use of
TARGET_OBJECTS outside of the context of generating the buildsystem,
as the path to object files may be dependent on buildsystem
variables (See bug #15226).
Commit v3.1.0-rc1~314^2 (Allow INTERFACE_SOURCES to specify
$<TARGET_OBJECTS> (#14970), 2014-07-09) made it possible to
propagate such content to dependent targets.
While that commit propagated the EvaluateForBuildsystem setting
for the case of a TARGET_PROPERTY expression, as generated for
direct dependencies of a target in
cmTargetInternals::AddInterfaceEntries, it did not add propagation
for content from further transitive target dependencies, as determined
by getLinkedTargetsContent.
This reverts commit v3.1.0-rc1~557^2~2 (ClearMatches: Only clear matches
which were actually set, 2014-03-12). The optimization did not track
the match count in the same scope as the variables, allowing possible
inconsistency.
Resolve conflicts in Source/cmIfCommand.cxx, Source/cmMakefile.cxx,
and Source/cmMakefile.h by moving the changes to the new location
of the code involved.
It gets incremented while entering a loop block (e.g. foreach or while)
and gets decremented when leaving the block. Because scope borders for
example at function borders must be taken into account the counter is
put into a stack. With every new scope an empty counter is pushed on the
stack, when leaving the scope the original value is restored.
This will allow easy querying if the break command is properly nested
within a loop scope.
Signed-off-by: Gregor Jasny <gjasny@googlemail.com>
7a687292 ccmake: Cleanup and simplify conditional blocks for HP-UX
44f02b42 ccmake: Use standard getmaxyx instead of non-standard getmax[xy]
ee3d06a4 ccmake: Remove incomplete support for cur_colr on old HP-UX
This commit fixes a bug where it was impossible to specify
/INCREMENTAL to Fortran projects built with Visual Studio.
The problem was due to the fact that .vfproj files expect
the value of this flag to be "linkIncremental{No,Yes},
whereas .vcproj files expect this value to be 0, 1, or 2.
The implementation of this fix adds a new data structure for
Visual Studio linker flags specific to Fortran. This can
easily be extended in the future if more such discrepencies
between C/C++ and Fortran linking are discovered.
Re-run if the input file changes or if the output file is removed.
This only works with the Makefile generators currently. The limitation
of the Ninja generator is tracked as issue #15256. The IDE
generators will need larger refactoring as they currently rely on
being able to determine the depends and output files at the start of
generate-time, which is too early for the file(GENERATE) case.
Ben Boeckel
Brad King
Kitware Robot
Stephen Kelly
Gregor Jasny
Ådne Hovda
Zack Galbreath