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)
- Move computation of extended build-tree rpath
to cmComputeLinkInformation
- Only enable the extended build-tree rpath if
the target will be installed
- Generalize the interface of file(CHRPATH)
- When changing the rpath on installation only
replace the part generated by CMake because
the native tools (ex SunCC on Linux) might have
added their own part to the rpath
- Add cmSystemTools::ChangeRPath method
- Add undocumented file(CHRPATH) command
- When installing use file(CHRPATH) to change the rpath
instead of relinking
- Remove CMAKE_CHRPATH lookup from CMakeFindBinUtils
- Remove CMAKE_USE_CHRPATH option since this should
always work
- Use linker search path -L.. -lfoo for lib w/out soname
when platform sets CMAKE_PLATFORM_USES_PATH_WHEN_NO_SONAME
- Rename cmOrderRuntimeDirectories to cmOrderDirectories
and generalize it for both soname constraints and link
library constraints
- Use cmOrderDirectories to order -L directories based
on all needed constraints
- Avoid processing implicit link directories
- For CMAKE_OLD_LINK_PATHS add constraints from libs
producing them to produce old ordering
Brad King
Bill Hoffman
Alexander Neundorf
Ken Martin