| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Commit v3.1.0-rc1~297^2~5 (cmTarget: Drop 'head' argument from
GetSourceFiles, 2014-07-10) exposed a dormant bug in source file computation,
causing the test case to regress. After that commit, the source file
computation and caching finds an existing container of source files. Prior to
that patch, the GetSourceFiles method was called with either a null pointer
for the head cmTarget, or it was called with the this pointer. The
processSources method is eventually called, which normalizes the difference
between the null pointer and the this pointer for the head target. However,
the cache key depends on the actual pre-normalized pointer. The change in
that commit caused the entry to be found in the cache where it was not before,
which resulted in incorrect behavior.
Prior to that commit, the test case also fails if the GetSourceFiles overload
taking a vector<cmSourceFile*> is changed to normalize the head target at
the beginning of the method:
cmTarget const* head = head_ ? head_ : this;
Such a construct was correctly used in other locations where similar caching
was in place, before being removed in commit v3.1.0-rc1~310^2~25 (cmTarget:
Remove 'head' argument from GetLinkInformation, 2014-06-12), but is not
neccessary anymore.
Commit v3.1.0-rc1~674^2~2 (cmTarget: Cache the cmSourceFiles in
GetSourceFiles., 2014-04-05) introduced the caching, but fails the test case
for an unrelated reason. That unrelated error was introduced in
commit v3.1.0-rc1~688^2~5 (cmTarget: Allow any generator expression in
SOURCES property., 2014-03-18) and fixed in
commit v3.1.0-rc1~561^2~1 (cmTarget: Fix listing of source files at
configure-time., 2014-04-13).
All commits which fail the test case in the testable way do so when such a
cached version of the source files is found and returned at generate
time. In the test case, the cached content is populated at configure-time
through the use of the deprecated LOCATION property with CMP0026 OLD. The
cached content is an empty container for the bar target in the test case,
because its source file 'foo.cpp.o' is not known until generate-time. That
means that no source files are available to compute the link language and
the reported error is issued.
The actual problem is that the SourceFilesMap should be cleared after
configure time by cmTarget::ClearLinkMaps. Clear it there now.
|
|\ |
|
| | |
|
| |
| |
| |
| | |
The error is raised if the *test* doesn't exist, not the property.
|
| |
| |
| |
| |
| | |
If either the test or the property doesn't exist, NOTFOUND will be used.
No error is raised in either case.
|
| |
| |
| |
| |
| | |
This was accidentally regressed by commit v3.1.0-rc1~812^2~50
(stringapi: Use strings for property names, 2013-09-02).
|
|\ \ |
|
| | |
| | |
| | |
| | | |
Otherwise the syntax is incorrect when the variable is empty.
|
|\ \ \ |
|
| |/ /
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
CMAKE_SYSTEM_PROCESSOR is not guaranteed to be defined (per
http://www.cmake.org/Wiki/CMake_Cross_Compiling), and when cross
compiling where it happens to be undefined, this module was broken.
Reviewed-by: Rolf Eike Beer <eike@sf-mail.de>
|
|\ \ \ |
|
| | |/
| |/|
| | |
| | | |
Do not quote if() arguments meant to test variable definitions.
|
|\ \ \ |
|
| | |/
| |/|
| | |
| | |
| | |
| | | |
Support was added in commit v3.1.0-rc1~475^2 (Features: Add support
for C++14 features., 2014-05-06), but the documentation for this
property was not amended.
|
|\ \ \ |
|
| | |/
| |/|
| | |
| | |
| | | |
When the variable is not defined the signature is actually accepting
a string. Also clarify fall-through from if(<constant>) case.
|
|\ \ \ |
|
| |/ / |
|
|\ \ \ |
|
| |/ /
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
The change in commit v3.1.0-rc1~174^2 (Makefile: Handle '#' in
COMPILE_OPTIONS, 2014-08-12) was not compatible with code that
tries to workaround the original bug. Unfortunately there is no
good way to fix the bug in a compatible way. Add a release note
to call attention to the change.
|
|\ \ \
| |_|/
|/| | |
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Add a test case that enables CXX in the top level and C in a subdirectory.
Create an executable in the top level that uses C objects compiled in the
subdirectory. Strictly speaking this is not defined behavior for all
language combinations, but happens to work in this case. Test this
behavior since projects might try to use it.
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Refactoring in commit v3.1.0-rc1~688^2~2 (cmTarget: Compute languages
from object libraries on demand, 2014-03-18) taught cmTarget::GetLanguages
to (correctly) include the languages of object library sources. Previously
this was done only in cmTarget::ComputeLinkImplementationLanguages to
choose the linker language.
The Ninja generator writes out generic build rules for each language
compiled within a target using the rule variables defined in the
directory of the target. This only needs to be done for languages
actually compiled within the current target. Switch from using the
cmTarget::GetLanguages method to get the list of languages over to
using cmTarget::GetSourceFiles directly so we do not get the languages
in object libraries.
Strictly speaking this should make no difference because it is not safe
to use objects from a language not enabled in the directory containing
a target or else the link information for the language may not be
considered. However, in cases when no link information happens to be
needed for a language it was possible in CMake 3.0 and below to enable
a language only in a subdirectory providing an object library, and then
use the objects from a containing directory. The above change teaches
the Ninja generator to continue working in this case.
|
|\ \ \
| |/ / |
|
| |/ |
|
|\ \ |
|
| |/ |
|
|\ \ |
|
| | |
| | |
| | |
| | |
| | |
| | | |
One piece of code has some ambiguous type deduction that seems to
resolve correctly for most compilers but not for the Oracle compiler.
Make it more explicit.
|
|\ \ \ |
|
| | |/
| |/|
| | |
| | |
| | |
| | |
| | | |
Explain the usage of each generator more clearly and reference each as
an alternative to the other.
Suggested-by: Craig Hicks <hicks111@hotmail.com>
|
|\ \ \
| | |/
| |/| |
|
| |/
| |
| |
| |
| |
| |
| |
| | |
In commit v3.1.0-rc2~7^2 (Workaround for short jump tables on PA-RISC,
2014-11-04) we added use of shell syntax not supported on the Solaris
shell. Avoid using the '!' operator.
Reported-by: Friedrich Haubensak <hsk@imb-jena.de>
|
|\ \
| |/
|/| |
|
| | |
|
|/ |
|
|\ |
|
| | |
|
|\ \
| |/
|/| |
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The use of FeatureSummary inside a find module is not a convention
yet used by upstream CMake modules. Drop the example from the
documentation about how to write find modules. If in the future
we add use of FeatureSummary to many of the upstream find modules
then this example can be restored as part of establishing the
convention.
|
| | |
|
|\ \ |
|
| |/
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The FindXerces module was added in commit v3.1.0-rc1~155^2 (FindXerces:
New module to find Apache Xerces-C++, 2014-08-17). However, there are
two implementations of Xerces, one in C++:
http://xerces.apache.org/xerces-c/
and one in Java:
http://xerces.apache.org/xerces-j/
Rename FindXerces to FindXercesC to clarify that it is about the C++
implementation.
While at it, add the missing CMake 3.1 release note about this module.
Suggested-by: Erik Sjölund <erik.sjolund@gmail.com>
|
|\ \ |
|
| |/
| |
| |
| |
| |
| |
| |
| | |
In commit v3.1.0-rc1~484^2 (Help: Format and revise file() command
documentation, 2014-05-23) the signature of file(GENERATE) was
accidentally simplified too much and dropped specification of the
required argument ordering. Restore the signature to make the order
clear.
|
|\ \ |
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
When a CMake domain 'command' object is defined by CMakeTransform or the
'cmake:command' directive, generate the link target with a lower-case
name even if the command name is not all lower-case. This is needed to
make cross-references to the command definition work since the
'cmake:command' role is marked with the 'lowercase' property.
|
|\ \ \ |
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
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.
|
|\ \ \ \
| |/ / / |
|