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.
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.
After discussing with Brad and Clinton:
-the namespace for the imported targets is now "Qt4::", tested with Makefiles, Visual Studio and XCode projects
-the imported targets are always created
-if QT_USE_IMPORTED_TARGETS is set to TRUE (it defaults to FALSE), the QT_QTFOO_LIBRARY variables are set to point to these imported
targets, otherwise the old behaviour is used.
-on OSX if Qt has been found as framework, disable QT_USE_IMPORTED_TARGETS, since cmake doesn't handle the framework directory as location of the library correctly
Alex
-set the type of the IMPORTED libraries to UNKNOWN, this way also on Windows
only the "LOCATION" property has to be set
-the if() around the SET(QT_${basename}_FOUND 1) was useless (always true)
-the mapping of the configuration types DEBUG and PROFILE did not belong here
Alex
This commit syncs FindQt4.cmake again with KDEs version.
Now for every Qt library an imported target with the name
Qt4ImportedTarget__<LIBNAME> is created.
This way we can now finally handle the release and debug versions of the Qt
libraries correctly.
Also, if a Qt-using project A installs a file with exported targets, these
targets now depend on the imported Qt targets, e.g.
Qt4ImportedTarget__QtCore. The location of QtCore is then resolved at
buildtime of project B, which uses the exported targets from project A.
Before this patch the full path to the QtCore on the original build machine
of project A was stored, so this had to match the directory layout on the
build machine for project B.
Alex
Zach Mullen
KWSys Robot
Bill Hoffman
Brad King
David Cole
James Bigler
Alexander Neundorf
Dave Partyka
Clinton Stimpson