With PushScope and PopScope, keeping track of another bit of data for
each scope isn't easy. Instead, store it as another CMake variable so it
gets implicitly tracked along with everything else.
This works in a revert of commit
7d674b5f0b.
Provide options to fail without blocking or to block up to a timeout.
Provide options to specify the scope containing the lock so it can be
released automatically at the end of a function, file, or process.
Extend the RunCMake.file test with cases covering the file(LOCK) command
usage and error cases.
Add a VS_DEPLOYMENT_LOCATION source file property to specify where to
put files that are part of the package. For example:
set_property(SOURCE ${ASSET_FILES} PROPERTY VS_DEPLOYMENT_LOCATION "assets")
Without this, sources marked with VS_DEPLOYMENT_CONTENT cannot be
located properly.
Create properties VS_SHADER_ENTRYPOINT and VS_SHADER_MODEL. Without
these many .hlsl source files may not be possible to use. Extend the
VSWinStorePhone test project to cover them.
When _UNICODE is defined VS uses wmain instead of main as the entry function.
To make this correctly work on WindowsCE EntryPointSymbol needs to be set to
mainWCRTStartup instead of mainACRTStartup for console applications and to
wWinMainCRTStartup instead of WinMainCRTStartup for GUI applications.
Signed-off-by: Pascal Bach <pascal.bach@siemens.com>
When checking target types for TARGET_SUPPORTS_SHARED_LIBS == false,
enumerate exactly the library types not supported rather than trying to
maintain a list of all the types that are supported. Otherwise
add_library(SomeImportedLib UNKNOWN IMPORTED)
warns on platforms that do not support shared libraries.
Reported-by: Kelly Thompson <kgt@lanl.gov>
Since commit v3.1.0-rc1~821^2 (Windows: Use response files to specify
link libraries for GNU tools, 2014-03-04) we use a response file to pass
possibly long linker flag lists to the GNU linker on Windows. On MinGW,
this may cause gfortran to use a response file to pass some flags to its
own internal invocation. This is okay except when we are parsing
implicit link flags from the compiler ABI detection build. If gfortran
uses a response file in that case then we may miss extracting some of
the implicit link flags, such as -lgfortran. Fortunately, in the
compiler ABI detection case we do not actually link to anything so the
response file is empty. Work around this problem by simply not using a
response file when the list of flags it is used to pass is empty (or
just whitespace).
Reported-by: Bill Somerville <bill@classdesign.com>
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>
Brad King
Kitware Robot
Ben Boeckel
Ruslan Baratov
Gilles Khouzam
Cedric Perthuis
Pascal Bach
Gregor Jasny
Stephen Kelly
Ådne Hovda