The MS tools create two types of PDB files as explained here:
http://msdn.microsoft.com/en-us/library/yd4f8bd1%28v=vs.71%29.aspxhttp://msdn.microsoft.com/en-us/library/yd4f8bd1%28v=vs.80%29.aspxhttp://msdn.microsoft.com/en-us/library/yd4f8bd1%28v=vs.90%29.aspxhttp://msdn.microsoft.com/en-us/library/yd4f8bd1%28v=vs.100%29.aspx
One is created by the compiler (/Fd) and the other by the linker (/pdb).
The two options should not specify the same file. Split them up.
In the VS IDE generators, simply drop ProgramDataBaseFileName to
take the VS default "/Fd$(IntDir)vc$(PlatformToolsetVersion).pdb".
In the Makefile generators, set "/Fd" on the compile line to be
the directory containing object files (with a trailing slash the
compiler will add the "vc$(PlatformToolsetVersion).pdb" filename
automatically). Drop the /Fd option from the exe link command
line and add "/pdb" instead (already done for dll linking).
Update these rules for both MSVC and Intel tools.
Drop support for PDB_OUTPUT_DIRECTORY and PDB_NAME in STATIC
libraries because the generated .pdb files are only from /Fd
and not real linker-generated .pdb files. Update documentation to
clarify that the PDB_* properties are only for linker .pdb files.
This regresses the PDBDirectoryAndName test for STATIC libraries.
Since it is not clear at this time what should be done for STATIC
library .pdb files, comment out the relevant portion of the test
and leave a TODO comment.
We can do this check only if the TargetName is non-empty, which means
that we're evaluating INTERFACE_INCLUDE_DIRECTORIES from a linked
dependency which was set using target_link_libraries.
It is possible to have relative paths in INCLUDE_DIRECTORIES already
in CMake 2.8.10.2, so that part will require a policy to fix.
It is considered an error if the INTERFACE_INCLUDE_DIRECTORIES contains
a directory which does not exist, which indicates a programmer error
by the upstream, or a packaging error.
One of the RunCMake.CompatibleInterface tests also needs to be updated
due to this change. Non-existant includes were used in the test, but
are not needed.
The API for retrieving per-config COMPILE_DEFINITIONS has long
existed because of the COMPILE_DEFINITIONS_<CONFIG> style
properties. Ensure that the provided configuration being generated
is also used to evaluate the generator expressions
in cmTarget::GetCompileDefinitions.
Both the generic COMPILE_DEFINITIONS and the config-specific
variant need to be evaluated with the requested configuration. This
has the side-effect that the COMPILE_DEFINITIONS does not need to
be additionally evaluated with no configuration, so the callers can
be cleaned up a bit too.
Rename the variable added by commit 9ce1b9ef (Add
CMAKE_BUILD_INTERFACE_INCLUDES build-variable, 2012-11-25) to
CMAKE_INCLUDE_CURRENT_DIR_IN_INTERFACE to be more consistent with the
existing CMAKE_INCLUDE_CURRENT_DIR variable.
Suggested-by: Alex Neundorf <neundorf@kde.org>
ab079ee Avoid crash when checking property compatibility without link info
92a2ab7 Avoid crash when checking property link dependencies without link info
Teach the compatibility check added by commit 042ecf04 (Add API to
calculate link-interface-dependent bool properties or error, 2013-01-06)
to return early if no link information is available. This avoids
crashing in a case that should fail with an error message.
Teach the isLinkDependentProperty helper added by commit e9879910 (Make
INTERFACE determined properties readable in generator expressions,
2013-01-19) to return early if no link information is available.
* Clarify accepted values of <LANG> suffix in CMAKE_COMPILER_IS_GNU<LANG>.
* Clarify fact that target property GENERATOR_FILE_NAME usually cannot be
used at configure time.
* Clarify that enable_language() can only be used in global scope of
top-level project using language.
* State that enable_language(... OPTIONAL) currently doesn't work.
* Document regular expression operator precedence.
Commit a1c4905f (Use the link information as a source of compile
definitions and includes., 2013-02-12) introduced the use of link
information as the source of target properties via the TARGET_PROPERTY
generator expression. This generator expression has a strict
interpretation of a valid target name and emits a fatal error for
invalid names.
Ensure that only targets with names valid for use with TARGET_PROPERTY
or targets which are determined by generator expressions are processed
by it. This means that at worst, invalid target names do not participate
in the transitive evaluation of properties, but the validation
generator expression can be extended where needed to resolve that.
As of commit 1da75022 (Don't include generator expressions in
old-style link handling., 2012-12-23), such entries are not
included in the LinkLibraries member. Generator expressions in
LinkLibraries are not processed anyway, so port to the new way
of getting link information.
This is similar in spirit to commit e48d8420 (Cache context-independent
includes on evaluation., 2013-02-03), but it is needed since commit
a1c4905f (Use the link information as a source of compile definitions
and includes., 2013-02-12), which changed how includes and defines
are determined. As they are now determined through the link interface,
we need to cache the result of evaluating them through that.
In the case of the includes, the result was already being cached
and then immediately disposed. Store the result as a member variable
instead to make use of the caching.
After evaluating the INTERFACE_INCLUDE_DIRECTORIES, of a target in a
generator expression, also read the INTERFACE_INCLUDE_DIRECTORIES of
its link interface dependencies.
That means that code such as this will result in the 'user' target
using /bar/include and /foo/include:
add_library(foo ...)
target_include_directories(foo INTERFACE /foo/include)
add_library(bar ...)
target_include_directories(bar INTERFACE /bar/include)
target_link_libraries(bar LINK_PUBLIC foo)
add_executable(user ...)
target_include_directories(user PRIVATE
$<TARGET_PROPERTY:bar,INTERFACE_INCLUDE_DIRECTORIES>)
Also process the interface include directories from direct link
dependencies for in-build targets.
The situation is similar for the INTERFACE_COMPILE_DEFINITIONS. The
include directories related code is currently more complex because
we also need to store a backtrace at configure-time for the purpose
of debugging includes. The compile definitions related code will use
the same pattern in the future.
This is not a change in behavior, as existing code has the same effect,
but that existing code will be removed in follow-up commits.
This is needed in the case that Automoc is used, as that calls
GetIncludeDirectories, which may cache the resulting include dirs
too early in the generate step.
Also, because the automoc step is so early, we can't cache the
include directories at that point. At that point the build interface
of all dependencies are not populated yet, so we'd be caching the
includes before appending the build interface. Only start caching
when we're definitely generating the buildsystem. At that point, the
includes should be stable.
We still need to invoke AppendBuildInterfaceIncludes
in the GlobalGenerator because the build interface includes affect
mostly the dependencies of targets (such as the automoc targets),
rather than the targets themselves, so the build interface needs
to be appended for all targets before generation is done.
This tracking was added during the development of commit 042ecf04
(Add API to calculate link-interface-dependent bool properties
or error., 2013-01-06), but was never used.
It was not necessary to use the content because what is really
useful in that logic is to determine if a property has been implied
to be null by appearing in a LINK_LIBRARIES genex.
I think the motivating usecase for developing the feature of
keeping track of the targets relevant to a property was that I
thought it would make it possible to allow requiring granular
compatibility of interface properties only for targets which
depended on the interface property. Eg:
add_library(foo ...)
add_library(bar ...)
add_executable(user ...)
# Read the INTERFACE_POSITION_INDEPENDENT_CODE from bar, but not
# from foo:
target_link_libraries(user foo $<$<TARGET_PROPERTY:POSTITION_INDEPENDENT_CODE>:bar>)
This obviously doesn't make sense. We require that INTERFACE
properties are consistent across all linked targets instead.
e48d842 Cache context-independent includes on evaluation.
089fe1c Optimize genex evaluation for includes and defines.
179f495 find_package: Reword <package>_NO_INTERFACES documentation
e7b579b Test workaround of bad interface include directories from depends.
77cecb7 Add includes and compile definitions with target_link_libraries.
0b92602 Add the $<LINKED:...> generator expression.
0fa7f69 Add API to check if we're reading a includes or defines property.
2c3654c Add a way to exclude INTERFACE properties from exported targets.
d4297d5 Export targets to a targets file, not a Config file.
df4d2b2 Make it an error for INSTALL_PREFIX to be evaluated.
7ceeba9 Advance more when preprocessing exported strings.
30268b4 Handle reading empty properties defined by the link interface.
The commit 18a3195a ('Keep track of INCLUDE_DIRECTORIES as a vector
of structs.', 2012-11-19) moved the handling of includes from
cmGeneratorTarget to cmTarget, but in the process introduced this
bug.
Generator expressions whose output depends on the configuration
now record that fact. The GetIncludeDirectories method can use
that result to cache the include directories for later calls.
GetIncludeDirectories is called multiple times for a target
for each configuration, so this should restore performance for
multi-config generators.
6063fef Output include directories as LOG messages, not warnings.
aa66748 Specify the target whose includes are being listed.
d70204a Only output includes once after the start of 'generate-time' when debugging.
0d46e9a Store includes from the same include_directories call together.
During configure-time, GetIncludeDirectories may be called too, for example
if using the export() command. As the content can be different, it should
be output each time then.
The cache here needs to be cleared if GetLinkInformation is called
at configure-time, such as during an export().
The next commit does exactly that, and without this patch,
the LinkLanguage test would fail.
It is not necessary and the current state is unintentional. Before
this patch,
target_link_libraries(foo bar)
causes the LINK_LIBRARIES property of foo to contain
$<TARGET_NAME:bar>
instead of just
bar
1d74ba2 Test evaluation target via export for generator expressions
522bdac Export the INTERFACE_PIC property.
4ee872c Make the BUILD_INTERFACE of export()ed targets work.
1d47cd9 Add a test for the interfaces in targets exported from the build tree.
6c828f9 Move the exported check for file existence.
cfd4f0a Move the exported check for dependencies of targets
d8fe1fc Only generate one check per missing target.
f623d37 Don't write a comment in the export file without the code.
b279f2b Strip consecutive semicolons when preprocessing genex strings.
Don't add generator expressions to variables which are used
for CMP0003, CMP0004, and the old-style _LIB_DEPENDS content. They
will not be evaluated when read anyway and would probably confuse
the code reading them.
This makes it legitimate to use target_link_libraries with generator
expressions as arguments.
The Config and IMPORTED_ variants may also contain generator
expressions.
If 'the implementation is the interface', then the result of
evaluating the expressions at generate time is used to populate
the IMPORTED_LINK_INTERFACE_LIBRARIES property.
1) In the case of non-static libraries, this is fine because the
user still has the option to populate the LINK_INTERFACE_LIBRARIES
with generator expressions if that is what is wanted.
2) In the case of static libraries, this prevents a footgun,
enforcing that the interface and the implementation are really
the same.
Otherwise, the LINK_LIBRARIES could contain a generator
expression which is evaluated with a different context at build
time, and when used as an imported target. That would mean that the
result of evaluating the INTERFACE_LINK_LIBRARIES property for
a static library would not necessarily be the 'link implementation'.
For example:
add_library(libone STATIC libone.cpp)
add_library(libtwo STATIC libtwo.cpp)
add_library(libthree STATIC libthree.cpp)
target_link_libraries(libtwo
$<$<STREQUAL:$<TARGET_PROPERTY:TYPE>,STATIC_LIBRARY>:libone>)
target_link_libraries(libthree libtwo)
If the LINK_LIBRARIES content was simply copied to the
IMPORTED_LINK_INTERFACE_LIBRARIES, then libthree links to libone, but
executables linking to libthree will not link to libone.
3) As the 'implementation is the interface' concept is to be
deprecated in the future anyway, this should be fine.
This allows a dependee to inform a target that it should have its
POSITION_INDEPENDENT_CODE property set to ON, or OFF. The value of
the POSITION_INDEPENDENT_CODE property, if set, must be consistent
with any INTERFACE_POSITION_INDEPENDENT_CODE properties on dependees.
Add a test covering the consistency checks on platforms where they run.
This new method checks that the property FOO on a target is consistent
with the INTERFACE_FOO properties of its dependees. If they are not the
consistent, an error is reported. 'Consistent' means that iff the
property is set, it must have the same boolean value as all other
related properties.
Previously we kept direct link dependencies in OriginalLinkLibraries.
The property exposes the information in the CMake language through the
get/set_property commands. We preserve the OriginalLinkLibraries value
internally to support old APIs like that for CMP0003's OLD behavior, but
the property is now authoritative. This follows up from commit d5cf644a
(Split link information processing into two steps, 2012-11-01).
This will be used later to populate the link interface properties when
exporting targets, and will later allow use of generator expressions
when linking to libraries with target_link_libraries.
Also make targets depend on the (config-specific) union of dependencies.
CMake now allows linking to dependencies or not depending on the config.
However, generated build systems are not all capable of processing
config-specific dependencies, so the targets depend on the union of
dependencies for all configs.
The 'head' is the dependent target to be linked with the current target.
It will be used to evaluate generator expressions with proper handling
of mapped configurations and is used as the source target of properties.
This requires that memoization is done with a key of a pair of target
and config, instead of just config, because now the result also depends
on the target. Removing the memoization entirely is not an option
because it slows cmake down considerably.
Use cmComputeLinkInformation::GetFrameworkPaths to get the list of
framework paths needed by the linker. Drop the now unused framework
information from the old-style cmTarget link dependency analysis.
The ComputePDBOutputDir added by commit 3f60dbf1 (Add
PDB_OUTPUT_DIRECTORY and PDB_NAME target properties, 2012-09-25) falls
back to the current binary directory instead of the target output
directory as before. When no PDB_OUTPUT_DIRECTORY property is set we
instead should fall back to the target output directory where .pdb files
used to go before the new property was added.
4ad0233 Remove period at the end of the check message.
50b1ea5 Fix minor typos.
19c3206 Remove unused parameter marker and the unused parameter.
9d462b2 Document that generator expressions can be used in target properties.
daf88c3 Fix punctuation in some variables documentation.
3172cde Fix the layout of the generator expression documentation.
2ccca05 Run PDBDirectoryAndName test on MSVC and Intel
efc83b3 Document that PDB_(NAME|OUTPUT_DIRECTORY) are ignored for VS 6
b294457 Verify that PDB_(NAME|OUTPUT_DIRECTORY) are honored in test
3f60dbf Add PDB_OUTPUT_DIRECTORY and PDB_NAME target properties (#10830)
This enables changing the name and output folder of the debug symbol
files produced by MS compilers.
Inspired-by: Thomas Bernard <thomas.bernard@ipetronik.com>
This reverts commit 987e12e2f9.
GenerateTargetManifest is called by the global generator before it
creates the generator targets, so we can't move it to cmGeneratorTarget
yet.
Removing the Process() API and removing the parameters from the
constructor will allow cmGeneratorExpressions to be cached and evaluated
with multiple configs for example, such as when evaluating target
properties. This requires the creation of a new compiled representation
of cmGeneratorExpression. The cmListFileBacktrace remains in the
constructor so that we can record where a particular generator
expression appeared in the CMakeLists file.
The POSITION_INDEPENDENT_CODE property documentation states that its
default value depends on whether SHARED or MODULE is given to the
add_library call. Since these are options to the add_library command we
should document on the command how they affect the property.
While at it, add a missing space to the POSITION_INDEPENDENT_CODE
property documentation.
CMAKE_SHARED_LIBRARY_<lang>_FLAGS has flags on various platforms for a
variety of purposes that are correlated with shared libraries but not
exclusive to them. Refactor generation of these flags to use new
purpose-specific platform variables
CMAKE_<lang>_COMPILE_OPTIONS_DLL
CMAKE_<lang>_COMPILE_OPTIONS_PIC
CMAKE_<lang>_COMPILE_OPTIONS_PIE
Activate the DLL flags specifically for shared libraries. Add a new
POSITION_INDEPENDENT_CODE target property to activate PIC/PIE flags, and
default to true for shared libraries to preserve default behavior.
Initialize the new property from CMAKE_POSITION_INDEPENDENT_CODE to
allow easy global configuration in projects.
Although the default behavior is unchanged by this refactoring, the new
approach ignores CMAKE_SHARED_LIBRARY_<lang>_FLAGS completely. We must
leave it set in case projects reference the value. Furthermore, if a
project modifies CMAKE_SHARED_LIBRARY_<lang>_FLAGS it expects the new
value to be used. Add policy CMP0018 to handle compatibility with
projects that modify this platform variable.
Add a PositionIndependentCode test on platforms where we can get
meaningful results.
Add a boolean target property NO_SONAME which may be used to disable
soname for the specified shared library or module even if the platform
supports it. This property should be useful for private shared
libraries or various plugins which live in private directories and have
not been designed to be found or loaded globally.
Replace references to <CMAKE_SHARED_LIBRARY_SONAME_${LANG}_FLAG> and
hard-coded -install_name flags with a conditional <SONAME_FLAG> which is
expanded to the value of the CMAKE_SHARED_LIBRARY_SONAME_${LANG}_FLAG
definition as long as soname supports is enabled for the target in
question. Keep expanding CMAKE_SHARED_LIBRARY_SONAME_${LANG}_FLAG in
rules in case third party projects still use it. Such projects would
not yet use NO_SONAME so the adjacent <TARGET_SONAME> will always be
expanded. Make <TARGET_INSTALLNAME_DIR> NO_SONAME aware as well. Since
-install_name is soname on OS X, this should not be a problem if this
variable is expanded only if soname is enabled.
The Ninja generator performs rule variable substitution only once
globally per rule to put its own placeholders. Final substitution is
performed by ninja at build time. Therefore we cannot conditionally
replace the soname placeholders on a per-target basis. Rather than
omitting $SONAME from rules.ninja, simply do not write its contents for
targets which have NO_SONAME. Since 3 variables are affected by
NO_SONAME ($SONAME, $SONAME_FLAG, $INSTALLNAME_DIR), set them only if
soname is enabled.
For now do not allow an OBJECT library to reference other object
libraries. Teach cmTarget::ComputeLinkImplementation to include the
languages of object libraries used by a target.
This library type can compile sources to object files but does not link
or archive them. It will be useful to reference from executable and
normal library targets for direct inclusion of object files in them.
Diagnose and reject the following as errors:
* An OBJECT library may not be referenced in target_link_libraries.
* An OBJECT library may contain only compiling sources and supporting
headers and custom commands. Other source types that are not normally
ignored are not allowed.
* An OBJECT library may not have PRE_BUILD, PRE_LINK, or POST_BUILD
commands.
* An OBJECT library may not be installed, exported, or imported.
Some of these cases may be supported in the future but are not for now.
Teach the VS generator that OBJECT_LIBRARY targets are "linkable" just
like STATIC_LIBRARY targets for the LinkLibraryDependencies behavior.
CMake does not automatically pass the Fortran module output directory
location to the module search path. Add a note to the documentation
that the location must also be specified by INCLUDE_DIRECTORIES.
d662dff Fix shadowed variable warning on dashboard results
f66e735 Fix compiler warning reported on older Borland dashboard.
d90eed4 Fix compiler error reported on older Borland dashboard.
8233636 Update the documentation regarding INCLUDE_DIRECTORIES.
d899eb7 Call ExpandVariablesInString for each target's INCLUDE_DIRECTORIES
c21db87 Make search paths ordered and unique
22021f0 Remove cmMakefile::GetIncludeDirectories
9106b56 Extract and use the INCLUDE_DIRECTORIES target properties.
840509b Keep the INCLUDE_DIRECTORIES target property up to date.
a4d5f7b Add API to get the ordered includes for a target.
8adaee2 CMake: Eliminate cmMakefile::IncludeDirectories
7620932 Remove include flags memoization.
97a5faa Make it safe to call this method without creating duplicates.
edd5303 Refactor GetIncludeFlags to take includes instead of fetching them
Remove partial implementation added by commit ca0230a3 (check in initial
conv library stuff, 2007-02-16) since it was never finished. It does
not make sense for multi-configuration generators since no specific
build configuration is processed at CMake time.
This allows downstreams to use
set(CMAKE_WIN32_EXECUTABLE ON)
set(CMAKE_MACOSX_BUNDLE ON)
to create executables with the WIN32_EXECUTABLE and MACOSX_BUNDLE
properties set on by default.
The purpose of the TargetType enumeration was overloaded for install
type because install rules were once recorded as targets. Factor the
install types out into their own enumeration.
VS_WINRT_EXTENSIONS: Boolean property that correspond to "Enable
Tailored Features" in Visual Studio 11 IDE.
VS_WINRT_REFERENCES: Semicolon-delimited list of *.winmd references to
add to the project, which creates a new <ItemGroup>.
automoc now defaults to strict mode, also with Qt4, i.e. it behaves as
the documentation says by default. I also inverted the switch
CMAKE_AUTOMOC_STRICT_MODE to CMAKE_AUTOMOC_RELAXED_MODE.
Docs and test adapted accordingly.
Alex
2d11951 Merge branch 'master' into AutomocIncludedDotMocFileHandling
1eca18f automoc: add documentation for CMAKE_AUTOMOC_STRICT_MODE
bc278ce automoc: fix line length
62e223e automoc: add variable CMAKE_AUTOMOC_STRICT_MODE, to enable strict parsing
40c5167 automoc: accept even more .moc files in non-strict mode
c207f5d automoc: also accept other files when .moc is included in non-strict mode
9c0df72 automoc: add a StrictParseCppFile(), which is only qmake-compatible
174bf35 automoc: move the code for finding headers into separate function
8507eae automoc: fix handling of included _p.moc files
7ada172 automoc: some more linebreaks for the warnings for better readability
3b93e26 automoc: add extra check whether the header contains Q_PRIVATE_SLOT
4745715 Add a test case for the use of Q_PRIVATE_SLOT.
bde4edb automoc: add special handling for including basename_p.moc, with test
74ab0f6 automoc: move some code from the big parsing loop into separate functions
bc7560e automoc: add test for including a moc_abc_p.cpp file
30fd8e6 automoc: add test for including the moc file from another header
...
ae62a1c Test CMAKE_GNUtoMS option in ExportImport on MinGW and MSys
afb00fe Add CMAKE_GNUtoMS option to convert GNU .dll.a to MS .lib
61e8629 Factor makefile generator link rule lookup into helper function
a603250 Load platform files that need to know the ABI when possible
ecd8414 Fortran: Detect pointer size in gfortran on MinGW
Teach the Windows-GNU.cmake platform file to look for Visual Studio
tools matching the target ABI. Add an extra step to the link command
for shared libraries and executables that export symbols and on which a
new GNUtoMS property is set (initialized by the CMAKE_GNUtoMS option).
Tell the GNU linker to output a module definition (.def) file listing
exported symbols in addition to the GNU-format import library (.dll.a).
Pass the .def file to the MS "lib" tool to construct a MS-format DLL
import library (.lib).
Teach the install(TARGETS) command to install the MS import library next
to the GNU one. Teach the install(EXPORT) and export() command to set
the IMPORTED_IMPLIB property pointing at the import library to use the
import library matching the tools in the importing project.
VS_GLOBAL_PROJECT_TYPES: A string containing UUIDs to embed in the
Visual Studio project file under <ProjectTypes>.
VS_GLOBAL_KEYWORD: Allows specification of a keyword like "ManagedCProj"
instead of the default "Win32Proj", under <Keyword>
VS_DOTNET_REFERENCES: Semicolon-delimited list of .NET references to add
to the project, which creates a new <ItemGroup>.
This commit adds a new target property AUTOMOC_MOC_OPTIONS, which
can be set to add extra options for the moc invocations done via automoc.
This is equivalent to the OPTIONS parameter in the qt4_wrap_cpp() macro.
Alex
Define variable CMAKE_LINK_INTERFACE_LIBRARIES to initialize the
value of this property when a target is created. This allows authors
to write
set(CMAKE_LINK_INTERFACE_LIBRARIES "")
to disable transitive linking to implementation dependencies of shared
libraries on platforms where it is possible.
Make it a static method instead of an array. It is safer for the
type checking and if we add a new target type we will be warned to add
a case to the switch.
Caveats apply: only valid when not overriding default value for output
dir *and* there is a CMAKE_XCODE_EFFECTIVE_PLATFORMS value.
For now, CMAKE_XCODE_EFFECTIVE_PLATFORMS must be defined in each
project, or in the cache for a build.
Code relying on value of LOCATION and similar properties may not
work if it depends on file existence on disk since CMake will not
evaluate $(EFFECTIVE_PLATFORM_NAME). This feature is only enabled
for making it easier to build Xcode iOS projects where the developer
wants to be able to switch easily between simulator and device builds.
Define a "Fortran_FORMAT" target and source file property. Initialize
the target property from a "CMAKE_Fortran_FORMAT" variable. Interpret
values "FIXED" and "FREE" to indicate the source file format. Append
corresponding flags to the compiler command line.
Thanks to Pau Garcia i Quiles for the inspiration for the patch.
I've tweaked it a bit compared to what's in the bug tracker: this
commit does not allow empty global variable names.
I also added usage of the new feature to an existing test. Although
it has no effect on the resulting Visual Studio projects, you can
verify that the VSResource test produces a non-empty globals section
in the generated .vcproj(x) files.
set_property() has APPEND, which creates a list. E.g. when
appending to COMPILE_FLAGS a string is needed, not a list.
With the APPEND_STRING option the value is append as string,
not as list.
Alex
Avoid GCC warning
warning: suggest parentheses around ‘&&’ within ‘||’ [-Wparentheses]
added by commit c6a8e4c7 (The link interface of MODULE libraries is
empty, 2011-03-09).
MODULE libraries cannot be linked into other libraries and executables
(just like executables without ENABLE_EXPORTS). Set the MODULE target
link interface to be empty. This allows such targets to be installed in
an EXPORT set without including all their private implementation
dependencies.
Commit afd7d4ca (Add target property LINK_SEARCH_END_STATIC, 2008-01-31)
defined a property to ensure that static runtime libraries get selected.
Add a property to specify that all libraries whose type is unknown, such
as "-lm", should be assumed static. Furthermore it assumes that an
option such as "-static" is also used so that no initial -Bstatic is
needed.
Although the LOCATION property is for compatibility with CMake 2.4, the
LOCATION_<CONFIG> property is modern. However, if a project reads it
and sets location-altering properties later the behavior is undefined.
See parent commit for details.
Reading the LOCATION target property currently locks down the result and
ignores any later changes to properties that affect it. This may or may
not be expected and may or may not be the behavior in earlier versions
of CMake. The property is documented as provided only for compatibility
with CMake 2.4 and alternative interfaces are now available for all
originally envisioned use cases. We want to discourage its use without
outright deprecating it. Add documentation to explicitly state that
reading the property before other properties are set is undefined.
4499d50 Mark CustomCommand test perconfig.out as SYMBOLIC
f0cdb60 Introduce "generator expression" syntax to custom commands (#11209)
4749e4c Record set of targets used in cmGeneratorExpression
ef9e9de Optionally suppress errors in cmGeneratorExpression
45e1953 Factor per-config sample targets out of 'Testing' test
4091bca Factor generator expression docs out of add_test
bfb7288 Record backtrace in cmCustomCommand
Evaluate in the COMMAND arguments of custom commands the generator
expression syntax introduced in commit d2e1f2b4 (Introduce "generator
expressions" to add_test, 2009-08-11). These expressions have a syntax
like $<TARGET_FILE:mytarget> and are evaluated during build system
generation. This syntax allows per-configuration target output files to
be referenced in custom command lines.
The soname generation code was compile-time selected instead of runtime
selected. The result is that a Mac-compiled cmake used to cross-compile
Mac -> Unix generates an soname of the form libfoo.x.y.so instead of
libfoo.so.x.y as expected. Instead do a runtime check based on the
target platform.
Inspired-By: George Staikos <staikos@kde.org>
Avoid tracing dependencies of GLOBAL_TARGET targets. The build system
generators are not designed to handle any dependencies that may be
discovered. Global targets are only generated by CMake and never have
commands that reference targets built in the project anyway.
The exception is when building CMake itself there is a special case to
use the just-built "cmake" binary in the "install" target so that CMake
can replace itself on Windows. Even in this special case we do not want
to let the "install" target depend on the "cmake" target. Doing so
breaks cases like "make -j4 install".
Imported targets do not themselves build, but we can follow dependencies
through them to find real targets. This allows imported targets to
depend on custom targets that provide the underlying files at build
time.
Factor out reading of CMAKE_CONFIGURATION_TYPES and CMAKE_BUILD_TYPE
into cmMakefile::GetConfigurations. Read the former only in
multi-config generators.
This work was started from a patch by Thomas Schiffer.
Thanks, Thomas!
See the newly added documentation of the FOLDER target
property for details.
Also added global properties, USE_FOLDERS and
PREDEFINED_TARGETS_FOLDER. See new docs here, too.
By default, the FOLDER target property is used to organize
targets into folders in IDEs that have support for such
organization.
This commit adds "solution folder" support to the Visual
Studio generators. Currently works with versions 7 through
10.
Also, use the new FOLDER property in the ExternalProject
test and in the CMake project itself.
Cygwin versions .dll files by putting the version number in the file
name. Our fix to issue #3571 taught CMake to do this, but it used the
VERSION target property. It is better to use the SOVERSION property
since that is the interface (rather than implementation) version.
Change based on patch from issue #10122.
We create per-configuration target properties to specify ARCHIVE,
LIBRARY, and RUNTIME output directories. The properties override the
generic properties for the <CONFIG> configuration:
ARCHIVE_OUTPUT_DIRECTORY -> ARCHIVE_OUTPUT_DIRECTORY_<CONFIG>
LIBRARY_OUTPUT_DIRECTORY -> LIBRARY_OUTPUT_DIRECTORY_<CONFIG>
RUNTIME_OUTPUT_DIRECTORY -> RUNTIME_OUTPUT_DIRECTORY_<CONFIG>
For multi-configuration generators, the per-configuration subdirectory
normally appended to the generic output directory is not added to the
configuration-specific property values. This allows projects to set the
exact location at which binaries will be placed for each configuration.
See issue #9163.
The CMAKE_OSX_ARCHITECTURES variable works only as a global setting.
This commit defines target properties
OSX_ARCHITECTURES
OSX_ARCHITECTURES_<CONFIG>
to specify OS X architectures on a per-target and per-configuration
basis. See issue #8725.
The commit "Target copy ctor should copy internal state" created a new
cmTargetInternals constructor but failed to initialize a POD member that
the original constructor initializes. This commit fixes it.
Ideally we should never copy cmTarget instances, but it is a pain to
remove current uses of it. The pimplized portion of cmTarget has mostly
members that cache results, but some are part of the object state.
These should be copied in the copy ctor instead of re-initialized.
In cmTarget we compute the link implementation, link interface, and link
closure structures on-demand and cache the results. This commit teaches
cmTarget to invalidate results after a LINK_INTERFACE_* property changes
or a new link library is added. We also clear the results at the end of
the Configure step to ensure the Generate step uses up-to-date results.
In cmTarget::SetProperty and cmTarget::AppendProperty we check whether
changing the property invalidates cached information. The check was
duplicated in the two methods, so this commit moves the check into a
helper method called from both.
This method is called during ConfigureFinalPass on every target. It
gives each target a chance to do some final processing after it is known
that no more commands will affect it. Currently we just call the old
AnalyzeLibDependencies that used to be called directly.
This commit creates target and directory properties to enable the Intel
interprocedural optimization support on Linux. Enabling it adds the
compiler option '-ipo' and uses 'xiar' to create archives.
See issue #9615.
This creates cmTarget::GetFeature and cmMakefile::GetFeature methods to
query "build feature" properties. These methods handle local-to-global
scope and per-configuration property lookup. Specific build features
will be defined later.
This converts the CMake license to a pure 3-clause OSI-approved BSD
License. We drop the previous license clause requiring modified
versions to be plainly marked. We also update the CMake copyright to
cover the full development time range.
In each target we trace dependencies among custom commands to pull in
all source files and build rules necessary to complete the target. This
commit teaches cmTarget to save the inter-source dependencies found
during its analysis. Later this can be used by generators that need to
topologically order custom command rules.
In cmTarget we trace the dependencies of source files in the target to
bring in all custom commands needed to generate them. We clean up the
implementation to use simpler logic and better method names. The new
approach is based on the observation that a source file is actually an
input (dependency) of the rule that it runs (compiler or custom) even in
the case that it is generated (another .rule file has the rule to
generate it).
This teaches cmTarget to use a set of cmSourceFile pointers to guarantee
unique insertion of source files in a target. The order of insertion is
still preserved in the SourceFiles vector.
We create target property "LINK_INTERFACE_MULTIPLICITY" and a per-config
version "LINK_INTERFACE_MULTIPLICITY_<CONFIG>". It sets the number of
times a linker should scan through a mutually dependent group of static
libraries. The largest value of this property on any target in the
group is used. This will help projects link even for extreme cases of
cyclic inter-target dependencies.
We creates methods IsDLLPlatform() and HasImportLibrary(). The former
returns true on Windows. The latter returns whether the target has a
DLL import library. It is true on Windows for shared libraries and
executables with exports.
The commit "Consider link dependencies for link language" taught CMake
to propagate linker language preference from languages compiled into
libraries linked by a target. It turns out this should only be done for
some languages, such as C++, because normally the language of the
program entry point (main) should be used.
We introduce variable CMAKE_<LANG>_LINKER_PREFERENCE_PROPAGATES to tell
CMake whether a language should propagate its linker preference across
targets. Currently it is true only for C++.
This factors the decision logic out of cmTarget::ComputeLinkClosure into
dedicated class cmTargetSelectLinker. We replace several local
variables with a single object instance, and organize code into methods.
Now that languages are part of the link interface of a target we need to
export/import the information. A new IMPORTED_LINK_INTERFACE_LANGUAGES
property and per-config IMPORTED_LINK_INTERFACE_LANGUAGES_<CONFIG>
property specify the information for imported targets. The export() and
install(EXPORT) commands automatically set the properties.
This teaches cmTarget to account for the languages compiled into link
dependencies when determining the linker language for its target.
We list the languages compiled into a static archive in its link
interface. Any target linking to it knows that the runtime libraries
for the static archive's languages must be available at link time. For
now this affects only the linker language selection, but later it will
allow CMake to automatically list the language runtime libraries.
The commit "Do not compute link language for LOCATION" was wrong. The
variables
CMAKE_STATIC_LIBRARY_PREFIX_Java
CMAKE_STATIC_LIBRARY_SUFFIX_Java
are used for building Java .jar files. This commit re-enables the
feature and documents the variables:
CMAKE_EXECUTABLE_SUFFIX_<LANG>
CMAKE_IMPORT_LIBRARY_PREFIX_<LANG>
CMAKE_IMPORT_LIBRARY_SUFFIX_<LANG>
CMAKE_SHARED_LIBRARY_PREFIX_<LANG>
CMAKE_SHARED_LIBRARY_SUFFIX_<LANG>
CMAKE_SHARED_MODULE_PREFIX_<LANG>
CMAKE_SHARED_MODULE_SUFFIX_<LANG>
CMAKE_STATIC_LIBRARY_PREFIX_<LANG>
CMAKE_STATIC_LIBRARY_SUFFIX_<LANG>
Instead of making separate, repetitive entries for the _<LANG> variable
documentation, we just mention the per-language name in the text of the
platform-wide variable documentation. Internally we keep undocumented
definitions of these properties to satisfy CMAKE_STRICT mode.
This passes the build configuration to most GetLinkerLanguage calls. In
the future the linker language will account for targets linked in each
configuration.
The LOCATION property requires the full file name of a target to be
computed. Previously we computed the linker language for a target to
look up variables such as CMAKE_SHARED_LIBRARY_SUFFIX_<LANG>. This led
to locating all the source files immediately instead of delaying the
search to generation time. In the future even more computation will be
needed to get the linker language, so it is better to avoid it.
The _<LANG> versions of these variables are undocumented, not set in any
platform file we provide, and do not produce hits in google. This
change just removes the unused feature outright.
The new method centralizes loops that process raw OriginalLinkLibraries
to extract the link implementation (libraries linked into the target)
for each configuration. Results are computed on demand and then cached.
This simplifies link interface computation because the default case
trivially copies the link implementation.
These member structures are accessed only in the cmTarget implementation
so they do not need to be defined in the header. This cleanup also aids
Visual Studio 6 in compiling them.
The config-to-interface map in cmTarget should use case-insensitive
configuration names. The change avoids repeating work if the given
configuration has a different case than one already computed.
This fixes a dumb logic error introduced by the centralization of link
interface computation. It prevented link directories from alternate
configurations from getting listed by the OLD behavior of CMP0003 for
targets linked as transitive dependencies.
This method previously required the global generator to be passed, but
that was left from before cmTarget had its Makefile member. Now the
global generator can be retrieved automatically, so we can drop the
method argument.
When LINK_INTERFACE_LIBRARIES is not set we use the link implementation
to implicitly define the link interface. These changes centralize the
decision so that all linkable targets internally have a link interface.
This moves code implementing policy CMP0004 into cmTarget::CheckCMP0004.
The implementation is slightly simpler and can be re-used outside of
cmComputeLinkDepends.
This fixes cmTarget::GetLinkInterface to compute and return the link
interface in an exception-safe manner. We manage the link interface
returned by cmTarget::ComputeLinkInterface using auto_ptr.
This creates cmTarget::GetOutputInfo to compute, cache, and lookup
target output directory information on a per-configuration basis. It
avoids re-computing the information every time it is needed.
The VMS posix path emulation does not handle multiple '.' characters in
file names in all cases. This avoids adding extra '.'s to file and
directory names for target directories and generated files.
Internally cmTarget was passing the target type in several name
computation signatures to support computation of both shared and static
library names for one target. We no longer need to compute both names,
so this change simplifies the internals by using the GetType method and
dropping the type from method signatures.
This property was left from before CMake always linked using full path
library names for targets it builds. In order to safely link with
"-lfoo" we needed to avoid having both shared and static libraries in
the build tree for targets that switch on BUILD_SHARED_LIBS. This meant
cleaning both shared and static names before creating the library, which
led to the creation of CLEAN_DIRECT_OUTPUT to disable the behavior.
Now that we always link with a full path we do not need to clean old
library names left from an alternate setting of BUILD_SHARED_LIBS. This
change removes the CLEAN_DIRECT_OUTPUT property and instead uses its
behavior always. It removes some complexity from cmTarget internally.
This creates target properties ARCHIVE_OUTPUT_NAME, LIBRARY_OUTPUT_NAME,
and RUNTIME_OUTPUT_NAME, and per-configuration equivalent properties
ARCHIVE_OUTPUT_NAME_<CONFIG>, LIBRARY_OUTPUT_NAME_<CONFIG>, and
RUNTIME_OUTPUT_NAME_<CONFIG>. They allow specification of target output
file names on a per-type, per-configuration basis. For example, a .dll
and its .lib import library may have different base names.
For consistency and to avoid ambiguity, the old <CONFIG>_OUTPUT_NAME
property is now also available as OUTPUT_NAME_<CONFIG>.
See issue #8920.
This creates method cmTarget::GetOutputTargetType to compute the output
file type 'ARCHIVE', 'LIBRARY', or 'RUNTIME' from the platform and
target type. It factors out logic from the target output directory
computation code for later re-use.
Linking to a Windows shared library (.dll) requires only its import
library (.lib). This teaches CMake to recognize SHARED IMPORTED library
targets that set only IMPORTED_IMPLIB and not IMPORTED_LOCATION.
When an IMPORTED target provides no generic configuration and no match
for a desired configuration then we choose any available configuration.
This change corrects the choice when the first listed available
configuration does not really have a location.
The add_definitions() command and COMPILE_DEFINITIONS dir/tgt/src
properties support preprocessor definitions with values. Previously
values were not supported in the VS6 generator even though the native
tool supports them. It is only values with spaces that VS6 does not
support. This enables support and instead complains only for values
with spaces. See issue #8779.
The RPATH target properties are initialized by CMAKE_<prop> variables at
target creation time. This notes the feature in the property
documentation. It is already noted in the variable documentation.
This defines global, directory, and target properties
RULE_LAUNCH_COMPILE, RULE_LAUNCH_LINK, and RULE_LAUNCH_CUSTOM. Their
values specify 'launcher' command lines which are prefixed to compile,
link, and custom build rules by Makefile generators.
This creates a new LABELS property for targets and source files. We
write the labels of each target and its source files in target-specific
locations in the build tree for future use.
This creates method cmTarget::GetSupportDirectory to compute a
target-specific support directory in the build tree. It uses the
"CMakeFiles/<name>.dir" convention already used by the Makefile
generators. The method will be useful for any code that needs to
generate per-target information into the build tree for use by CMake
tools that do not run at generate time.
Previously cmTarget::GetLocation and cmTarget::GetFullPath would return
for Mac AppBundles the top-level bundle directory but without the .app
extension. We worked around this at the call sites. This fixes the
methods and removes the work-arounds. See issue #8406.
Previously we left the LOCATION property undefined for imported targets
since it should no longer be used for non-imported targets. However, in
the case we do not know the name of an available imported configuration,
it is more readable to get the LOCATION property than LOCATION_<CONFIG>
for a bogus configuration <CONFIG>. This enables LOCATION for imported
targets and returns an unspecified available imported configuration.
The CMAKE_<CONFIG>_POSTFIX variable and <CONFIG>_POSTFIX property were
not documented. This updates the CMAKE_DEBUG_POSTFIX and DEBUG_POSTFIX
documentation to refer to the more general variable/property. It also
clarifies that the variable is used as the property default only for
non-executable targets. See issue #7868.
In some cases it may be useful to compute a "link" line for a static
library even though it will not be put in the generated build system.
This removes the assertion which previously diallowed the case.
A Mac OS X Framework should provide a Resources/Info.plist file
containing meta-data about the framework. This change generates a
default Info.plist for frameworks and provides an interface for users to
customize it.
The LINK_INTERFACE_LIBRARIES target property may not contain the
"debug", "optimized", or "general" keywords. These keywords are
supported only by the target_link_libraries (and link_libraries) command
and are not a generic library list feature in CMake. When a user
attempts to add one of these keywords to the property value, we now
produce an error message that refers users to alternative means.
The LINK_INTERFACE_LIBRARIES property does not apply for STATIC
libraries. The IMPORTED_LINK_INTERFACE_LIBRARIES property does apply
for STATIC libraries. State both explicitly in the documentation.
Also, clarify that the per-configuration version of these properties
completely overrids the generic version.
When creating an IMPORTED target for a library that has been found on
disk, it may not be known whether the library is STATIC or SHARED.
However, the library may still be linked using the file found from disk.
Use of an IMPORTED target is still important to allow per-configuration
files to be specified for the library.
This change creates an UNKNOWN type for IMPORTED library targets. The
IMPORTED_LOCATION property (and its per-config equivalents) specifies
the location of the library. CMake makes no assumptions about the
library that cannot be inferred from the file on disk. This will help
projects and find-modules import targets found on disk or specified by
the user.
In switch statements that deal with only a few target types, use a
'default' case for the remaining target types instead of listing them
explicitly. This will make it easier to add more types in the future.
This change introduces policy CMP0008 to decide how to treat full path
libraries that do not appear to be valid library file names. Such
libraries worked by accident in the VS IDE and Xcode generators with
CMake 2.4 and below. We support them in CMake 2.6 by introducing this
policy. See policy documentation added by this change for details.
- Create MACOSX_BUNDLE_INFO_PLIST target property to specify template.
- Look for MacOSXBundleInfo.plist.in in CMAKE_MODULE_PATH by default.
- See issue #6983.
- Previously this was done implicitly by the check for a target
link language which checked all source full paths.
- The recent change to support computing a link language without
finding all the source files skipped the implicit check.
- This change adds an explicit check to find all source files.
- Place the built library in foo.framework/Versions/A/foo
- Do not create unused content symlinks (like PrivateHeaders)
- Do not use VERSION/SOVERSION properties for frameworks
- Make cmTarget::GetDirectory return by value
- Remove the foo.framework part from cmTarget::GetDirectory
- Correct install_name construction and conversion on install
- Fix MACOSX_PACKAGE_LOCATION under Xcode to use the
Versions/<version> directory for frameworks
- Update the Framework test to try these things
- Policy is WARN by default so projects will build
as they did in 2.4 without user intervention
- Remove CMAKE_LINK_OLD_PATHS variable since it was
never in a release and the policy supercedes it
- Report target creation backtrace in warning message
since policy should be set by that point
- Add cmListFileBacktrace to record stack traces
- Move main IssueMessage method to the cmake class instance
(make the backtrace an explicit argument)
- Change cmMakefile::IssueMessage to construct a backtrace
and call the cmake instance version
- Record a backtrace at the point a target is created
(useful later for messages issued by generators)
Brad King
Stephen Kelly
Petr Kmoch
Yuchen Deng
David Cole
Nicolas Despres
Modestas Vainius
Eugene Golushkov
Alex Neundorf
Aaron Ten Clay
Robert Dailey
Richard Bateman
Bill Hoffman
Ken Martin