Sort include directives within each block (separated by a blank line) in
lexicographic order (except to prioritize `sys/types.h` first). First
run `clang-format` with the config file:
---
SortIncludes: false
...
Commit the result temporarily. Then run `clang-format` again with:
---
SortIncludes: true
IncludeCategories:
- Regex: 'sys/types.h'
Priority: -1
...
Commit the result temporarily. Start a new branch and cherry-pick the
second commit. Manually resolve conflicts to preserve indentation of
re-ordered includes. This cleans up the include ordering without
changing any other style.
Use the following command to run `clang-format`:
$ git ls-files -z -- \
'*.c' '*.cc' '*.cpp' '*.cxx' '*.h' '*.hh' '*.hpp' '*.hxx' |
egrep -z -v '(Lexer|Parser|ParserHelper)\.' |
egrep -z -v '^Source/cm_sha2' |
egrep -z -v '^Source/(kwsys|CursesDialog/form)/' |
egrep -z -v '^Utilities/(KW|cm).*/' |
egrep -z -v '^Tests/Module/GenerateExportHeader' |
egrep -z -v '^Tests/RunCMake/CommandLine/cmake_depends/test_UTF-16LE.h' |
xargs -0 clang-format -i
This selects source files that do not come from a third-party.
Inspired-by: Daniel Pfeifer <daniel@pfeifer-mail.de>
Ensure that cmStandardIncludes.h is included before any platform header
in cmGeneratorExpressionEvaluator.h. That file needs to change as
a result of removal of the cmMakefile.h header from
cmGeneratorExpressionNode.h, affecting the compilation of
cmGeneratorExpressionNode.cxx.
On AIX we need to include our own headers first to get large file
support macros defined consistently within system headers. The old
order in this header worked only because it was always included after
other headers.
1c1c2a12 cmGeneratorTarget: Port ExpandLinkItems away from cmTarget.
c66084f5 cmGeneratorTarget: Port GetImportLinkInterface away from cmTarget.
83c29e39 cmGeneratorTarget: Port ComputeLinkImplementationLibraries away from cmTarget.
19882554 cmGeneratorTarget: Port handleSystemIncludesDep away from cmTarget.
c1f687b1 cmGeneratorTarget: Port GetLinkImplementationLibrariesInternal.
a6e1f05c cmGeneratorTarget: Port ComputeLinkInterface away from cmTarget.
654002fe cmGeneratorTarget: Port ComputeLinkInterfaceLibraries away from cmTarget.
922c8901 cmGeneratorTarget: Port GetLinkInterface away from cmTarget.
eaa5b9cb cmGeneratorTarget: Port cmTargetCollectLinkLanguages away from cmTarget.
f539da12 cmGeneratorTarget: Port GetLinkInterfaceLibraries away from cmTarget.
1c5d70f9 cmGeneratorTarget: Port processILibs away from cmTarget.
064c2488 cmComputeLinkDepends: Port some API to cmGeneratorTarget.
3e428fdc cmGeneratorTarget: Move IsImportedSharedLibWithoutSOName from cmTarget.
110fd2fb cmGeneratorTarget: Move GetOutputTargetType from cmTarget.
e7391699 cmGeneratorTarget: Move HasMacOSXRpathInstallNameDir from cmTarget.
c5718217 cmGeneratorTarget: Move HaveInstallTreeRPATH from cmTarget.
...
Instead of storing just the string names in these structures, lookup any
target associated with each item and store its cmTarget pointer. Use
the cmLinkItem class to hold the name and pointer together. Update
client sites to use the pre-stored lookup result instead of looking up
the target name again.
Create a cmTarget::LookupLinkItems helper method to handle the lookup.
Since lookups are now moving from cmComputeLinkDepends::AddLinkEntries
to cmTarget::LookupLinkItems, move use of CheckCMP0004 to the latter.
This drops use of CheckCMP0004 from entries added for _LIB_DEPENDS
variables by cmComputeLinkDepends::AddVarLinkEntries, but I do not
think that use was intentional originally anyway.
Casts from std::string -> cmStdString were high on the list of things
taking up time. Avoid such implicit casts across function calls by just
using std::string everywhere.
The comment that the symbol name is too long is no longer relevant since
modern debuggers alias the templates anyways and the size is a
non-issue since the underlying methods are generated since it's
inherited.
This has follow-on effects for other methods and classes. Further
work on making the use of const cmTarget pointers common can be
done, particularly with a view to generate-time methods.
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.
Since commit 183b9509 (Follow all dependencies of shared library private
dependencies, 2011-12-14) we honor LINK_INTERFACE_LIBRARIES when
following dependent shared libraries. The link interface properties may
form a cycle if set incorrectly by a project. Furthermore, the property
LINK_DEPENDENT_LIBRARIES may form a cycle if set incorrectly by hand
(though CMake should never generate one). In either case, do not follow
the cycle forever when following the dependent shared library closure.
We only need to add dependency edges to the constraint graph once.
Add "LinkInterfaceLoop" test to cover this case.
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.
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.
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.
The transitive link dependencies of a linked target must be followed in
its own scope, not in the scope of the original target that depends on
it. This is necessary since imported targets do not have global scope.
See issue #8843.
This change introduces a new algorithm for link line construction. The
order it computes always begins with the exact link line specified by
the user. Dependencies of items specified by the user are tracked, and
those that are not already satisified by the line are appended to it at
the end with minimal repeats. This restores the behavior of CMake 2.4
and below while still fixing some of its bugs. See issue #7546.
In cmComputeLinkDepends link items that look like flags (starting in
'-') should not be included in dependency inferral. They are not
libraries and therefore have no dependencies. They should just be
passed through to the final link line unchanged. See issue #7546.
When an executable target within the project is named in
target_link_libraries for another target, but the executable does not
have the ENABLE_EXPORTS property set, then the executable cannot really
be linked. This is probably a case where the user intends to link to a
third-party library that happens to have the same name as an executable
target in the project (or else will get an error at build time). We
need to avoid making the other target depend on the executable target
incorrectly, since the executable may actually want to link to that
target and this is not a circular depenency.
In CMake 2.4 the generated link line for a target always preserved the
originally specified libraries in their original order. Dependencies
were satisfied by inserting extra libraries into the line, though it had
some bugs. In CMake 2.6.0 we preserved only the items on the link line
that are not known to be shared libraries. This reduced excess
libraries on the link line. However, since we link to system libraries
(such as /usr/lib/libm.so) by asking the linker to search (-lm), some
linkers secretly replace the library with a static library in another
implicit search directory (developers can override this by using an
imported target to force linking by full path). When this happens the
order still matters.
To avoid this and other potential subtle issues this commit restores
preservation of all non-target items and static library targets. This
will create cases of unnecessary, duplicate shared libraries on the link
line if the user specifies them, but at least it will work. In the
future we can attempt a more advanced analysis to safely remove
duplicate shared libraries from the link line.
- CMake 2.4 added link directories for targets linked
in the optimized configuration even when building debug
- Old behavior for policy CMP0003 must account for this
- Move Tarjan algorithm from cmComputeTargetDepends
into its own class cmComputeComponentGraph
- Use cmComputeComponentGraph to identify the component DAG
of link dependencies in cmComputeLinkDepends
- Emit non-trivial component members more than once but always
in a contiguous group on the link line
- Split IMPORTED_LINK_LIBRARIES into two parts:
IMPORTED_LINK_INTERFACE_LIBRARIES
IMPORTED_LINK_DEPENDENT_LIBRARIES
- Add CMAKE_DEPENDENT_SHARED_LIBRARY_MODE to select behavior
- Set mode to LINK for Darwin (fixes universal binary problem)
- Update ExportImport test to account for changes
- Created cmExportFileGenerator hierarchy to implement export file generation
- Installed exports use per-config import files loaded by a central one.
- Include soname of shared libraries in import information
- Renamed PREFIX to NAMESPACE in INSTALL(EXPORT) and EXPORT() commands
- Move addition of CMAKE_INSTALL_PREFIX to destinations to install generators
- Import files compute the installation prefix relative to their location when loaded
- Add mapping of importer configurations to importee configurations
- Rename IMPORT targets to IMPORTED targets to distinguish from windows import libraries
- Scope IMPORTED targets within directories to isolate them
- Place all properties created by import files in the IMPORTED namespace
- Document INSTALL(EXPORT) and EXPORT() commands.
- Document IMPORTED signature of add_executable and add_library
- Enable finding of imported targets in cmComputeLinkDepends
- This will be useful for imported library dependencies
- Replaces old cmTarget analyze-lib-depends stuff for linking
- Formalizes graph construction and dump
- Explicitly represents dependency inferral sets
- Use BFS of initial dependencies to preserve order
Brad King
Stephen Kelly
Ben Boeckel