CTest 2.6.4 crashes if a dashboard script invokes "message()" after
"ctest_test()" or anything else that creates an inner cmCTest object.
The CMake.Install test drives installation using --build-and-test with
the outer CTest driving CMake tests. We add --force-new-ctest-process
to avoid creation of a cmCTest object inside the outer CTest just in
case it is 2.6.4.
The compiler documents symbols _DF_VERSION_ and _VF_VERSION_ but they do
not seem to be available to the preprocessor. Instead we add a vendor
query table entry for Compaq. Running "f90 -what" produces
Compaq Visual Fortran Optimizing Compiler Version ...
This clearly identifies the compiler.
At least one Fortran compiler does not provide a preprocessor symbol to
identify itself. Instead we try running unknown compilers with version
query flags known for each vendor and look for known output. Future
commits will add vendor-specific flags/output table entries.
At least one Fortran compiler does not provide a preprocessor symbol to
identify itself. Instead we try running unknown compilers with version
query flags known for each vendor and look for known output. Future
commits will add vendor-specific flags/output table entries.
The PathScale compiler silently accepts unknown options that start in
more than one '-':
$ touch foo.c
$ pathcc -c foo.c --junk
$ echo $?
0
$ pathcc -c foo.c ---junk
$ echo $?
0
$ pathcc -c foo.c -junk
pathcc ERROR parsing -junk: unknown flag
$ echo $?
2
We teach the TryCompile to pass a bogus flag with only one '-' instead
of three '-'s for this compiler.
We disable this test because PathScale Fortran mangles module symbols as
"MYSUB.in.MYMODULE" so we cannot interface with it from C. We already
did this for SunPro and MIPSpro.
PathScale Fortran mangles module symbols as "MYSUB.in.MYMODULE" and also
requires "mymodule_" when the module is imported. We cannot provide the
symbol with ".in." mangling so we should not provide "mymodule_" because
it would duplicate the one in the Fortran-provided object file.
In commit "use export all symbols on cygwin" (2003-01-21) we started
passing -Wl,--export-all-symbols when linking shared libraries. Now
cygwin exports all symbols automatically if no symbols are explicitly
exported. When symbols are explicitly exported we want to honor that
narrow interface. Therefore this flag should not be passed.
Change based on patch from issue #10122.
The variable should contain the name of a library needed to link the
symbol equivalent to dlopen. On Cygwin no special library is needed,
and certainly not "gdi32".
Change based on patch from issue #10122.
KWSys Robot
CMake Robot
Bill Hoffman
Zach Mullen
Brad King
David Cole
James Bigler
Alexander Neundorf
Dave Partyka