| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| |
|
|
|
|
|
|
|
| |
During installation the RPATH and RUNPATH entries of ELF binaries are
edited to match the user specification. Usually either one entry is
present or both entries refer to the same string literal. In the case
that they are both present and refer to separate string literals we need
to update both. I have never seen this case in practice, but we should
do this just in case.
|
| |
|
|
|
|
|
|
| |
Removal of the RPATH and RUNPATH from ELF binaries must work when both
entries are present. Both entries should be removed. Previously only
one would be removed and the other would be blanked because it pointed
at the same string which was zeroed. This fixes gentoo bug number
224901.
|
| | |
|
| | |
|
| |
|
|
|
| |
When find_package is about to look in <prefix>/lib, search first in
<prefix>/lib64 in cases that find_library would use lib64 paths.
|
| |
|
|
|
| |
Visual Studio 6 does not support per-target object files, so just use two
separate source file names in this case.
|
| |
|
|
| |
Alex
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
| |
Create an INTERFACE option to the target_link_libraries command to help
set the LINK_INTERFACE_LIBRARIES and LINK_INTERFACE_LIBRARIES_DEBUG
properties. This will help users specify link interfaces using
variables from Find*.cmake modules that include the 'debug' and
'optimized' keywords.
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
| |
The "debug", "optimized", and "general" link library type specifier
arguments to the target_link_library commands are sometimes repeated in
user code due to variable expansion and other complications. Instead of
silently accepting the duplicates and trying to link to a bogus library
like "optimized.lib", warn and ignore the earlier specifiers.
|
| |
|
|
|
|
| |
The add_subdirectory() command's EXCLUDE_FROM_ALL option does not
override inter-target dependencies. This change clarifies the
documentation accordingly.
|
| |
|
|
|
|
| |
A recent change fixed a case in which CMake incorrectly diagnosed a
circular dependency involving a non-linkable executable target. This
adds a test for that case.
|
| |
|
|
|
|
|
|
|
|
|
| |
Compiler INFO strings built at preprocessing time encode information
that must appear as a string literal in the resulting binary. We must
make sure the strings appear in the final binary no matter what compiler
and flags are used. The previous implementation worked in most places
but failed with the GNU linker's --gc-sections option which managed to
discard the string. Instead we make the program return value depend on
an element of the string indexed by a runtime program parameter, which
absolutely requires the string to be present.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
When an executable target within the project is named in
target_link_libraries for another target, but the executable does not
have the ENABLE_EXPORTS property set, then the executable cannot really
be linked. This is probably a case where the user intends to link to a
third-party library that happens to have the same name as an executable
target in the project (or else will get an error at build time). We
need to avoid making the other target depend on the executable target
incorrectly, since the executable may actually want to link to that
target and this is not a circular depenency.
|
| |
|
|
|
|
| |
When reporting the dependencies in a strongly connected component quote
the target names to make the message more readable no matter the target
name.
|
| |
|
|
|
|
| |
After reporting an error about circular target dependencies do not try
to continue generation because the dependency computation object is not
in a useful state.
|
| |
|
|
| |
Alex
|
| |
|
|
| |
Alex
|
| | |
|
| |
|
|
|
|
| |
LIBRARY_OUTPUT_PATH are empty
Alex
|
| | |
|
| |
|
|
| |
Alex
|
| |
|
|
|
|
|
| |
As of CMake 2.6 a custom command output specified by relative path is
placed in the build tree. This adds a test to make sure other
references to the output are hooked up correctly, fixing a bug in CMake
2.6.1.
|
| |
|
|
|
|
|
|
| |
Custom command dependencies that are not full paths or targets may also
match source files. When one does, the full information about the
source file's location and name may be used. This fixes the case when a
custom commands depends by relative path on a source file generated by
another custom command specifying its output by relative path.
|
| |
|
|
|
|
|
|
| |
A name with an ambiguous extension may only match an unambiguous name
that is extended by one of the fixed set of extensions tried when
finding the source file on disk. This rule makes matching of source
files with ambiguous extensions much less aggressive but still
sufficient.
|
| |
|
|
|
|
| |
When generating RPATH entries on the link line using a repeated linker
flag (-R ... -R ... style) do not convert individual entries to a full
path. We need to preserve what the user requested.
|
| |
|
|
|
|
|
| |
When generating escape sequences for the native build tool do not put in
Makefile escapes for paths generated into link scripts. This fixes
putting "$ORIGIN" into the RPATH, and probably some other subtle
problems.
|
| | |
|
| |
|
|
|
|
| |
Creation of archive libraries with the unix 'ar' tool should be done
incrementally when the number of object files is large. This avoids
problems with the command line getting too many arguments.
|
| |
|
|
|
|
| |
When attempting to load the RPATH out of a non-ELF file cmELF would
crash because the check for a valid file was done with in correct
operator precedence. See bug#7392.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
a file during coverage analysis.
|
| |
|
|
| |
Visual Studio + SDK combinations
|
| | |
|
| | |
|
| |
|
|
| |
output on _WIN32 since sometimes the drive letters have different case.
|
| | |
|
| | |
|
