All global generator CreateLocalGenerator methods automatically
initialize the local generator instances with SetGlobalGenerator. In
several places we were calling SetGlobalGenerator again after receiving
the return value from CreateLocalGenerator. The double-initializations
leaked the resources allocated by the first call to SetGlobalGenerator.
This fix removes the unnecessary calls.
We list implicit link items of languages linked into a target but filter
them by the implicit libraries known to be passed by the main linker
language. Implicit link flags like "-z..." should not be filtered out
because they are not libraries.
The Sun Fortran compiler passes -zallextract and -zdefaultextract to the
linker so that all objects from one of its archives are included in the
link. This teaches the implicit options parser to recognize the flags.
We need to pass them explicitly on C++ link lines when Fortran code is
linked.
In cmComputeLinkInformation we recognize link options that look like
library file names, but pass flags starting in '-' through untouched.
This fixes the ordering of the check to recognize '-' flags first in
case the rest of the option looks like a library file name, as in the
case of "-l:libfoo.a".
In cmComputeLinkInformation we construct regular expressions to
recognize library file names. This fixes the expressions to not allow a
colon (':') in the file name so that "-l:libfoo.a" is left alone.
Some AIX/gcc version combinations the <cstdio> header breaks when large
file support is enabled. See this GCC issue for details:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20366
We work around the problem by enhancing the configuration check for
large file support to include <cstdio> when available. This will cause
LFS to be disabled when the above problem occurs.
This extends the Fortran-to-C interface test to add a C++ source file.
The executable can only link with the C++ linker and with the proper
Fortran runtime libraries. These libraries should be detected by CMake
automatically, so this tests verifies the detection functionality.
This hack was created to help the Fortran test executables link to the
implicit C libraries added by BullsEye. Now that implicit libraries
from all languages are detected and included automatically the hack is
no longer needed.
This adds implicit libraries and search directories for languages linked
into a target other than the linker language to its link line. For
example, when linking an executable containing both C++ and Fortran code
the C++ linker is used but we need to add the Fortran libraries.
The variables
CMAKE_<LANG>_IMPLICIT_LINK_LIBRARIES
CMAKE_<LANG>_IMPLICIT_LINK_DIRECTORIES
contain the implicit libraries and directories for each language.
Entries for the linker language are known to be implicit in the
generated link line. Entries for other languages that do not appear in
the known implicit set are listed explicitly at the end of the link
line.
This teaches the SystemInformation test to report the CMake log files
CMakeOutput.log and CMakeError.log from the CMake build tree and from
the SystemInformation test build tree. These logs may help diagnose
dashboard problems remotely.
This extends the Fortran/C interface test to require that the executable
link to the fortran language runtime libraries. We must verify that the
proper linker is chosen.
The commit "Avoid case change in ImplicitLinkInfo test" did not change
all of the paths to mingw, so some case change still occurs. This
changes more of them.
The "Keep only FinalPass commands in memory" commit caused instances of
this command to be deleted after the InitialPass. Even though the
variable_watch command does not have a final pass, it does need to stay
alive because it owns the callback information.
In cmMakefile we save all invoked commands so that FinalPass can be
called on them later. Most commands have no final pass, so we should
keep only the few that do.
This removes the file-wise installation rules for Modules and Templates
and instead installs the whole directories. This approach is much less
error-prone. The old approach was left from before CMake had the
install(DIRECTORY) command.
Since "get_filename_component(... ABSOLUTE)" retrieves the actual case
for existing paths on windows, we need to use an obscure path for mingw.
Otherwise the test can fail just because the case of the paths changes.
Xcode adds extra link directories that point at the build tree, so
detection of implicit link directories is not reliable. Since Fortran
is not supported in Xcode we will not need implicit link information yet
anyway.
This tests the internal CMakeParseImplicitLinkInfo.cmake module to
ensure that implicit link information is extracted correctly. The test
contains many manually verified examples from a variety of systems.
This teaches CMake to detect implicit link information for C, C++, and
Fortran compilers. We detect the implicit linker search directories and
implicit linker options for UNIX-like environments using verbose output
from compiler front-ends. We store results in new variables called
CMAKE_<LANG>_IMPLICIT_LINK_LIBRARIES
CMAKE_<LANG>_IMPLICIT_LINK_DIRECTORIES
The implicit libraries can contain linker flags as well as library
names.
This teaches the language configuration modules to load per-compiler
information for each language using the compiler id but no system name.
They look for modules named "Compiler/<id>-<lang>.cmake". Such modules
may specify compiler flags that do not depend on the platform.
This teaches the command to recognize full windows paths when built on
UNIX. CollapseFullPath knows when the input path is relative better
than FileIsFullPath because the latter is only meant for paths from the
host platform.
Previously each new variable scope (subdirectory or function call) in
the CMake language created a complete copy of the key->value definition
map. This avoids the copy using transitive lookups up the scope stack.
Results of queries answered by parents are stored locally to maintain
locality of reference.
The class cmDefinitions replaces cmMakefile::DefinitionsMap, and is
aware of its enclosing scope. Each scope stores only the definitions
set (or unset!) inside it relative to the enclosing scope.
The command "set(... PARENT_SCOPE)" should never affect the calling
scope. This improves the Function test to check that such calls in a
subdirectory scope affect the parent but not the child.