Response files are parsed by tools, not by shells. We teach
cmLocalGenerator::Convert() a new "RESPONSE" output format and use it
for objects listed in response files. It does not do special slash or
MSYS root translation like the "SHELL" format does. This is necessary
for GNU tools on Windows to understand response file content.
See issue #10401.
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.
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 cmLocalGenerator::ConvertToRelativePath we normally convert to
relative path only if the local and remote paths both lie inside the
source tree or both lie inside the build tree. This commit adds an
optional 'force' argument to allow conversion even when this rule is
violated.
This method tells the cmMakefile to read the input CMakeLists.txt file.
We factor out the call into a ReadInputFile method so it can be extended
without polluting the Configure method.
Much of the code in this method was dedicated to computing ObjectMaxPath
after configuring the directory. We move this last step into its own
ComputeObjectMaxPath method for better organization.
This fixes CMAKE_<LANG>_IMPLICIT_INCLUDE_DIRECTORIES to be used for all
generators instead of just those that construct their own compiler
command lines directly. See issue #8598.
We used to suppress generation of -I/usr/include (and on OSX also
-I/usr/local/include). This behavior seems to cause more trouble than
it's worth, so I'm removing it until someone encounters the original
problem it fixed. See issue #8598.
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.
When an object file directory is too deep to place an object file
without exceeding CMAKE_OBJECT_PATH_MAX, this issues a warning.
Previously we silently ignored the problem. See issue #7860.
When computing the maximum length full path to the build directory under
which object files will be placed, pass the actual path instead of just
its length. This will be useful for error message generation.
These changes refactor cmLocalGenerator methods Convert and
ConvertToOutputForExisting to support references inside the build tree
using relative paths. After this commit, all tests pass with Makefile
generators when relative paths are enabled by default. See issue #7779.
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.
Some native build tools, particularly those for cross compiling, may
have a limit on the length of the full path to an object file name that
is lower than the platform otherwise supports. This change allows the
limit to be set by the project toolchain file through the variable
CMAKE_OBJECT_PATH_MAX.
- This is purely an implementation improvement. No interface has changed.
- Create cmComputeLinkInformation class
- Move and re-implement logic from:
cmLocalGenerator::ComputeLinkInformation
cmOrderLinkDirectories
- Link libraries to targets with their full path (if it is known)
- Dirs specified with link_directories command still added with -L
- Make link type specific to library names without paths
(name libfoo.a without path becomes -Wl,-Bstatic -lfoo)
- Make directory ordering specific to a runtime path computation feature
(look for conflicting SONAMEs instead of library names)
- Implement proper rpath support on HP-UX and AIX.
installing without having to link the target again -> can save a lot of time
chrpath is handled very similar to install_name_tool on the mac. If the
RPATH in the build tree file is to short, it is padded using the separator
character.
This is currently disabled by default, it can be enabled using the option
CMAKE_USE_CHRPATH. There are additional checks whether it is safe to enable
it. I will rework them and use FILE(READ) instead to detect whether the
binaries are actually ELF files.
chrpath is available here
http://www.tux.org/pub/X-Windows/ftp.hungry.com/chrpath/
or kde svn (since a few days): http://websvn.kde.org/trunk/kdesupport/chrpath/
Alex
function which returns the RPATH, so e.g. the install rpath can be queried
when the command for the build rpath is created. This is a first step for
supporting chrpath.
Alex
CMake-SourceFile2-bp and CMake-SourceFile2-b-mp1 to trunk. This
commit is surrounded by tags CMake-SourceFile2-b-mp1-pre and
CMake-SourceFile2-b-mp1-post on the trunk.
The changes re-implement cmSourceFile and the use of it to allow
instances to be created much earlier. The use of cmSourceFileLocation
allows locating a source file referenced by a user to be much simpler
and more robust. The two SetName methods are no longer needed so some
duplicate code has been removed. The strange "SourceName" stuff is
gone. Code that created cmSourceFile instances on the stack and then
sent them to cmMakefile::AddSource has been simplified and converted
to getting cmSourceFile instances from cmMakefile. The CPluginAPI has
preserved the old API through a compatibility interface.
Source lists are gone. Targets now get real instances of cmSourceFile
right away instead of storing a list of strings until the final pass.
TraceVSDependencies has been re-written to avoid the use of
SourceName. It is now called TraceDependencies since it is not just
for VS. It is now implemented with a helper object which makes the
code simpler.
GetLocaGenerators(cmLocalGenerators) from cmGlobalGenerator(). Now there is
one const accessor which is even faster since it returns a reference
(instead of copying a vector)
-more const to ensure that this the returned local generators don't actually
get modified
-removed duplicated code in GetCTestCommand() and GetCPackCommand()
-added some const accessors
Alex
add_custom_target() as COMMAND, and cmake will recognize them and replace
them with the actual output path of these executables. Also the dependency
will be added automatically. Test included.
ENH: moved TraceVSDependencies() to the end of GlobalGenerator::Configure(),
so it is done now in one central place
Alex
fix many bugs related to target names being computed inconsistently.
- Centralized computation of a target's file name to a method in
cmTarget. Now that global knowledge is always available the
*_CMAKE_PATH cache variables are no longer needed.
- Centralized computation of link library command lines and link
directory search order.
- Moved computation of link directories needed to link CMake targets
to be after evaluation of linking dependencies.
This also removed alot of duplicate code in which each version had its
own bugs.
This commit is surrounded by the tags
CMake-TargetNameCentralization1-pre
and
CMake-TargetNameCentralization1-post
so make the large set of changes easy to identify.
Alex Neundorf
Brad King
Bill Hoffman
Ken Martin
Andy Cedilnik