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.
CMakeFindBinUtils sets CMAKE_RANLIB to `:` if it is not available in
order to get a no-op. This does not work on a Windows host build
environment that runs commands in `cmd` instead of `sh`. Teach the
Ninja and Makefile generators to simply skip the command if it is `:`.
This this was already done by the Makefile generator since commit
v2.6.0~3161 (BUG: Do not write link script lines that use the ':',
2006-06-18), but only when using a link script.
Reported-by: Michael Jäntsch <Michael.Jaentsch@gmx.de>
In commit v3.6.0-rc1~100^2 (libarchive: Drop early use of crypto
library, 2016-05-03) we accidentally dropped the include directory for
OpenSSL as well as the library. Without that, it works only
accidentally when CHECK_CRYPTO happens to choose the OpenSSL
implementation and add the include directory.
Reported-by: Bradley Lowekamp <blowekamp@mail.nih.gov>
After finding it in `foo.Framework/Headers/dir/header.h`, we should
report the `foo.Framework/Headers` directory, not
`foo.Framework/Headers/dir`, because the former is what actually
contains the path the caller wishes to include.
Add a unit test to test the new functions to export JAR targets. The
test builds three sub-projects: two that generate and export a JAR (one
does a build-directory-only export, one an install-only export), and a
third that consumes the first two as imported targets.
Add additional functions to UseJava.cmake to create "exported" targets,
similar to those of C/C++ libraries. In support of this, ensure that the
JAR_FILE property of jar targets is always an absolute path.
Brad King
Robert Maynard
Tobias Hunger
Vladimír Vondruš
Boris Fomitchev
Daniel Pfeifer
Matthew Woehlke
Stuart Mentzer
Kitware Robot
Stephen Kelly
Matthäus G. Chajdas
Roger Leigh
Harry Mallon