Some SGI compilers define _SGI_COMPILER_VERSION in addition to the old
_COMPILER_VERSION preprocessor symbol. It is more distinctive, so we
should check it in case the old one is ever removed.
The SGI preprocessor /usr/lib/cpp produces bad output on this code:
#if 1
A
#elif 1
B
#else
C
#endif
Both 'A' and 'C' appear in the output! We work around the problem by
using '#elif 1' instead of '#else'.
This fixes detection of the SGI Fortran compiler id in -o32 mode.
This factors code out of cmOrderDirectories::CollectOriginalDirectories
into cmOrderDirectories::AddOriginalDirectories. Later a new call will
be added, and this is more readable anyway.
The ExportImport test drives its Export and Import projects using the
same compiler and flags. This converts the ctest --build-and-test
command lines to use an initial cache file instead of passing all
settings on the command line.
We need a shorter command line to pass through VS 6 on Win98.
This approach reduces duplicate code anyway.
Add System_Parse_CommandForUnix to the KWSys System interface as a
utility to parse a unix-style command line. Move the existing
implementation out of ProcessUNIX. Add a flags argument reserved for
future use in providing additional behavior.
This teaches the ExternalProject module to check the download URL file
name. If it is not a tarball (.tar, .tgz, .tar.gz) it is an error
because UntarFile does not yet understand other archive formats.
When tarball extraction fails we should still cleanup the temporary
extraction directory. Otherwise the next attempt will create a new
directory and the first one will never be removed.
This teaches Modules/Platform/Linux-SunPro-CXX.cmake the -rpath-link flag. The
SunPro C++ compiler does not have a '-Wl,' option, so we just pass the flag
directly.
This problem was exposed by the ExportImport test now that it links an
executable through the C++ compiler with the -rpath-link flag.
cmCTestScriptHandler, but have it load the new script CTestScriptMode.cmake
-> that makes it more flexible, also add a simple test that the system name
has been determined correctly
Alex
Now that languages are part of the link interface of a target we need to
export/import the information. A new IMPORTED_LINK_INTERFACE_LANGUAGES
property and per-config IMPORTED_LINK_INTERFACE_LANGUAGES_<CONFIG>
property specify the information for imported targets. The export() and
install(EXPORT) commands automatically set the properties.
This extends the ExportImport test. The Export project creates a C++
static library and exports it. Then the Import project links the
library into a C executable. On most platforms the executable will link
only if the C++ linker is chosen correctly.
Xcode does not seem to support direct requests for using the linker for
a particular language. It always infers the linker using the languages
in the source files. When no user source files compile with target's
linker language we add one to help Xcode pick the linker.
A typical use case is when a C executable links to a C++ archive. The
executable has no C++ source files but we need to use the C++ linker.
This test creates a C executable that links to a C++ static library. On
most platforms the executable will not link unless the C++ linker is
chosen correctly.
This teaches cmTarget to account for the languages compiled into link
dependencies when determining the linker language for its target.
We list the languages compiled into a static archive in its link
interface. Any target linking to it knows that the runtime libraries
for the static archive's languages must be available at link time. For
now this affects only the linker language selection, but later it will
allow CMake to automatically list the language runtime libraries.