Since Qt 5.4.2, it is necessary to compile against Qt 5 with -fPIC
and not -fPIE when using GCC 5. Not doing so results in a hanging
test in this case, so use the PIC flag directly instead.
In commit v3.2.0-rc1~480^2 (QtAutogen: Regenerate qrc files if their input
changes, 2014-09-17) the "cmake -E cmake_autogen" rule was switched from
always running to running as a custom command with dependencies if rcc
is enabled. This is not correct because automoc always needs to re-run.
Switch back to always running the command.
8bcec4d2 Help: Add notes for topic 'GNUInstallDirs-special-prefixes'
c8bd37ec GNUInstallDirs: Add special cases for certain prefixes
5f30f175 GNUInstallDirs: Add test cases
54676a0e Help: Add notes for topic 'ConcurrentFortran-compiler-id'
7cd539b1 Add support for Concurrent Fortran 77 Compiler
0d204c1c CMakeDetermineCompilerId: Try matching compiler output to detect id
5f0dad75 CMakeDetermineCompilerId: Refactor id build/check loop logic
c65a060e CMakeDetermineCompilerId: Optionally try some flags before no flags
At least some versions (e.g. C++ Builder 5) of the bcc32 linker are known to
write temporary files with a constant name to the current directory (e.g.
"turboc.$ln"). (This can be verified by using Process Monitor to watch the
file writes that bcc32 / ilink32 / implib make). This causes problems with
some generators that keep a constant current directory and run concurrent
linkers.
For example, the Ninja generator, by default, always has the current directory
set to the top of the build tree - resulting in conflicts between the linkers
that are simultaneously trying to write to "turboc.$ln". Symptoms include
direct errors regarding the "turboc.$ln" file, or later build steps failing due
to corrupted output from previous links that happened to link "successfully."
This is not a problem for the Borland Makefiles generator which does not
run jobs in parallel. For the Ninja generator, work around this problem
by using a link job pool of size 1.
The Concurrent Fortran compiler (ccur.com) is available on Linux and can
be used much like the GNU Fortran compiler. Currently it has no
preprocessor symbols to identify it so we need to detect it by matching
compiler output.
Suggested-by: Anthony Ette <Anthony.R.Ette@controlsdata.com>
Some compilers can only be distinguished by their compilation output
rather than preprocessor symbols or special flags. Add infrastructure
to determine the compiler id by matching output.
Callers of CMAKE_DETERMINE_COMPILER_ID initialize the
CMAKE_${lang}_COMPILER_ID to unset so we can check it at the end of each
loop iteration instead of the beginning. This approach allows us to
break out of the loop as soon as we succeed. It will also allow checks
to be added in more places within the loop later.
Teach CMAKE_DETERMINE_COMPILER_ID to optionally try detecting the
compiler id using some given flags before trying to detect it with no
special flags. This will be useful for Fortran detection to distinguish
some compilers that use the preprocessors of others but have no macro of
their own by getting verbose output.
Teach the module to handle SYSCONFDIR and LOCALSTATEDIR properly if
CMAKE_INSTALL_PREFIX is set to `/` or `/usr` -- i.e. as expected by GNU
Coding Standard (i.e. set SYSCONFDIR to `/etc` and `LOCALSTATEDIR` to
`/var`). Also if CMAKE_INSTALL_PREFIX is set to /opt/pkg, `SYSCONFDIR`
must be set to `/etc/opt/pkg` and `LOCALSTATEDIR` to `/var/opt/pkg`
according to FHS.
Add a RunCMake.GNUInstallDirs test with cases covering various install
prefixes. Hard-code the architecture information. Tolerate all
platform-specific LIBDIR values.
Currently the root prefix is not handled well, but verify the current
behavior in the test anyway. This can be addressed with a future
change.
Inspired-by: Alex Turbov <i.zaufi@gmail.com>
Stephen Kelly
Kitware Robot
Brad King
James Johnston
Alex Turbov