The fix in commit v3.2.3~3^2 (Fix assertion failure on unmatched foreach
in function, 2015-05-18) broke handling of unmatched non-loop blocks
because it assumed all function blockers removed during error unwinding
were for loops, essentially switching the set of mishandled cases.
The purpose of the loop block push/pop operations is to define a scope
matching the lifetime of the loop function blockers. Since our function
blockers already have the proper lifetime, simply move the push/pop
operations to their constructor/destructor.
Extend the RunCMake.Syntax test with a case covering this.
The cmListFileArgument currently stores a FilePath for use in this
method. The filename is the same as the CMAKE_CURRENT_LIST_FILE,
except if executing a macro or function defined in another file.
Set the context filename when expanding the arguments of macros and
functions using the filename recorded when defining the prototype.
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.