| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Since commit v2.8.8~173^2 (FindRuby: clean up querying variables from
Ruby, 2012-02-17) we query RbConfig::CONFIG first and, if the command
fails or its output equates to a false constant, then fall back to
querying Config::CONFIG.
Due to the above, an error condition exists with Ruby 2.2.0; when
querying RbConfig::CONFIG['TEENY'], the output of '0' will be discarded
since it matches the false constant '0'.
In previous versions this wasn't a problem, but Ruby 2.2 has completely
removed Config::CONFIG. This causes RUBY_VERSION_PATCH to be set to an
empty string and the Ruby version to be detected as '2.2.' (instead of
'2.2.0').
Fix the output check to explicitly look for an empty string before using
the fallback query method. (Someone more familiar with Ruby might be
able to deem the fallback as unnecessary and fully remove it.)
|
| | |
|
| |\ |
|
| | | |
|
| |\ \
| |/
|/| |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| | |
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.
|
| |\ \ \ \
| |/ / / |
|
| | | |/
| |/|
| | |
| | |
| | |
| | | |
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.
|
| |\ \ \ |
|
| | |/ /
| | |
| | |
| | | |
Typo "ss defined" => "as defined".
|
| |\ \ \ |
|
| | |/ / |
|
| |\ \ \ |
|
| | |/ / |
|
| |\ \ \ |
|
| | |/ /
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
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>
|
| |\ \ \ |
|
| | |/ /
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Revert the feature added by commit v3.1.0-rc1~420^2~2 (FindOpenGL:
Provide imported targets for GL and GLU, 2014-05-31). Unfortunately it
does not work on Windows because the full path to each library file is
not actually known. The IMPORTED_LOCATION of an imported target must be
a full path, but OPENGL_gl_LIBRARY is just 'opengl32' on Windows because
the actual library file is in some implicit link directory that we may
know know.
More infrastructure will be needed in CMake to allow a name-only
imported library. Until that exists, we will not be able to provide
imported targets in FindOpenGL.
|
| |\ \ \ |
|
| | | | |
| | | |
| | | |
| | | |
| | | | |
This bug was introduced in "FindPythonInterp: rework the version detection"
7d6db93de9ffc6e6092fa722aaf9c057dadcd634.
|
| |\ \ \ \ |
|
| | | |/ /
| |/| |
| | | |
| | | | |
Fix spelling 'execptions' => 'exceptions'.
|
| |\ \ \ \ |
|
| | |/ / /
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
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>
|
| |\ \ \ \
| |_|/ /
|/| | | |
|
| | |/ /
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
In commit v3.1.0-rc1~640^2~5 (Clean up usage of if(... MATCHES regex)
followed string(REGEX REPLACE regex), 2014-04-06) we accidentally broke
logging of the implicit library detection. Restore use of the
intermediate 'lib' variable so that the log message is constructed
properly.
Reported-by: Bill Somerville <bill@classdesign.com>
|
| |\ \ \ |
|
| | | | | |
|
| |\ \ \ \ |
|
| | | | | | |
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
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.
|
| |\ \ \ \ |
|
| | |/ / /
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
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.
|
| |\ \ \ \ |
|
| | | | | | |
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Since commit v3.1.0-rc1~479^2~1 (Add an "installed file" property
scope, 2014-05-15) the get_property and set_property commands
support an 'INSTALL' scope. Add documentation for this scope.
|
| | | |/ /
| |/| | |
|
| |\ \ \ \ |
|
| | | |/ /
| |/| | |
|
| |\ \ \ \ |
|
