dc1d025 OS X: Add test for rpaths on Mac.
8576b3f OS X: Add support for @rpath in export files.
00d71bd Xcode: Add rpath support in Xcode generator.
94e7fef OS X: Add RPATH support for Mac.
RPATH support is activated on targets that have the MACOSX_RPATH
property turned on.
For install time, it is also useful to set INSTALL_RPATH to help
find dependent libraries with an @rpath in their install name.
Also adding detection of rpath conflicts when using frameworks.
This fixes bug #13797.
The kinds of changes applied in 373faae5 for frameworks are now
applied to CFBundle. The prefix and suffix for CFBundles are
now handled in cmTarget::GetFullNameInternal.
This corresponds to the g++ and clang++
option -fvisibility-inlines-hidden on linux. On Windows with MinGW,
this corresponds to -fno-keep-inline-dllexport. That option is
not supported by clang currently.
This is initialized by CMAKE_<LANG>_VISIBILITY_PRESET. The target
property is used as the operand to the -fvisibility= compile option
with GNU compilers and clang.
They can't be used when evaluating link libraries, but they can be
used for include directories and compile definitions. Later they can
be used for compile options.
Make handling of directory separators consistent between
non-bundle and bundle code.
Remove xcode specific flag from cmTarget when getting install_name.
Add (more) consistent convenience functions in cmTarget to get
directories inside of bundles and frameworks to add files to.
This refactor also fixes bug #12263 where frameworks
had the wrong install name when SKIP_BUILD_RPATH.
Also make install_name for frameworks consistent between Makefile
and Xcode generator.
This allows for example, the buildsystem to use names like 'boost_any'
instead of the overly generic 'any', and still be able to generate
IMPORTED targets called 'boost::any'.
Commit 42ebb188 (Memoize includes and defines from interface libraries.,
2013-02-22) introduced caching of the includes. Fix the memoization to
be configuration-specific so that we do not accumulate entries across
multiple evaluations in a multi-config generator.
Generator expressions, including configuration-specific expressions may
be used as link libraries of targets. The old-style keywords of
target_link_libraries are handled in terms of new generator expressions.
However, the generator expressions expect target names to be valid
against a regular expression, whereas target_link_libraries does not
require validation. In generator expression constructed without any
action from the user we need to ensure that only valid expressions are
generated. Ensure that strings which are not valid target names are not
used in generator expressions which validate the argument.
Code like
target_link_libraries(B debug A)
generates usage requirement references such as "$<$<CONFIG:DEBUG>:A>".
When cmTarget::GetIncludeDirectories uses such references it generates
expressions like:
$<TARGET_PROPERTY:$<$<CONFIG:DEBUG>:A>,INTERFACE_INCLUDE_DIRECTORIES>
When the conditions are false such references evaluate as an empty
string and the expression fails with an error such as:
$<TARGET_PROPERTY:tgt,prop> expression requires a non-empty target name.
Fix this by teaching cmTarget::GetIncludeDirectories to wrap the above
expression inside a conditional:
$<$<BOOL:$<$<CONFIG:DEBUG>:A>>:...>
so that $<TARGET_PROPERTY:...> will not be evaluated with an empty
target.
Maintain a target's internal list of usage requirement include
directories whenever the LINK_LIBRARIES property is set by either
target_link_libraries or set_property.
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.
Brad King
Clinton Stimpson
Stephen Kelly
John Farrier
Rolf Eike Beer
Andreas Mohr
Petr Kmoch
Yuchen Deng
David Cole
Nicolas Despres
Modestas Vainius
Eugene Golushkov
Alex Neundorf
Aaron Ten Clay
Robert Dailey
Richard Bateman