ea5324cd cmMakefile: Port messages for compile features to cmake
df8c3130 cmGlobalGenerator: Don't use cmMakefile::IssueMessage after configure
946d1e50 cmMakefile: Avoid IssueMessage after configure is finished
096c7754 cmLocalGenerator: Store Backtrace for the directory
f62ed322 cmLocalGenerator: Add GetTargetDefines to get all defines for a target
853b1bb4 cmLocalGenerator: Constify AppendDefines and AddCompileDefinitions
The makefile is only used when called by the cmMessageCommand, so inline
the use of it there. It otherwise creates an undesirable dependency on
cmMakefile for issuing messages in the cmake instance, a violation of
the Interface Segregation Principle.
https://en.wikipedia.org/wiki/Interface_segregation_principle
This also makes it more explicit that the variable definitions only
affect the message() command. If an AUTHOR_WARNING is issued for any
other reason, it is not affected. To affect that, it is necessary to
set the cache variable instead of the regular variable.
This is an unfortunate interface quirk, but one which can't be fixed
easily now.
Rename memtester.cxx.in to memtester.cxx, run clang-format, then restore
the original name. Fix the @_retval@ placeholder that was broken by
clang-format.
Add a ``FIND_LIBRARY_USE_LIB32_PATHS`` global property analogous to the
``FIND_LIBRARY_USE_LIB64_PATHS`` property. This helps find commands on
multilib systems that use ``lib32`` directories and either do not have
``lib`` symlinks or point ``lib`` to ``lib64``.
When we are on OSX and we are launching cmake-gui from a symlink, the
application will fail to launch as it can't find the qt.conf file which
tells it what the name of the plugin folder is. We need to add this path
BEFORE the application is constructed as that is what triggers the
searching for the platform plugins
0bd91ad4 UseJava: Fix race condition creating java class list
89df91b9 Help: Add notes for topic 'java-export-targets'
95d84369 Tests: Add test for exported JARs
5341c0d8 UseJava: Add infrastructure to export targets
d91ec044 Tests/Java: Clean up style of Java test code
Modify logic to unconditionally create an empty class list response file
to instead only create the empty file if no classes are being compiled.
Otherwise, the response file is created via a custom command that
generates the correct list.
This fixes a race condition on certain systems (e.g. HFS on OS X) where
the dependency for creating the "correct" list can have the "same" (due
to limited precision of the filesystem) timestamp as the empty file
created at configure time, resulting in an empty class list being
incorrectly used to invoke `jar` (resulting in `jar` being unhappy that
it was not given any input files). Although one would have some hope
that this doesn't affect "real" projects, it definitely does affect the
JavaExportImport unit test, causing the same to fail randomly when run
on an HFS partition.
The fix in commit v3.4.0-rc1~127^2 (Tests: Fix Plugin test on Watcom
compiler, 2015-09-03) was reverted accidentally by automated .c_str()
removal. Restore it and add a comment explaining why.