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.
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.
63e5eb5f Help: Add notes for 'productbuild' topic
2e3c67d1 productbuild: Add new productbuild cpack generator.
50a3d340 PackageMaker: factor out common code for creating pkg files.
c3a281fd FindBoost: Search in official Windows prebuilt binary library directory
3720d5f4 FindBoost: Test `CMAKE_CXX_COMPILER_{ID,VERSION}` instead of `MSVC*`
We use file(GLOB) to load the list of files produced by compiling the
compiler identification source. Encode square brackets in the path to
the directory so that they are not treated as special characters in the
globbing expression. Otherwise we fail to find any files when the path
contains square brackets and the compiler id is unknown.
Reported-by: Esch Nigma <eschnigma@openmailbox.org>
In commit v2.6.0~3438 (ENH: Better support for adding and removing path,
2006-04-27) an include of "WinMessages.NSH" was added without removing
the original include. Remove it now.
Policy CMP0026 deprecated the LOCATION property, and we have long
provided a $<TARGET_FILE:...> generator expression. However, if
a project tries to use $<TARGET_PROPERTY:...,LOCATION> we should
at least not crash.
The compatibility implementation of the LOCATION property uses
cmGlobalGenerator::CreateGenerationObjects to create the structures
needed to evaluate the property before generation starts. The
implementation assumed that accessing the property could only be done
during configuration (via the typical get_property command use case).
The $<TARGET_PROPERTY:...,LOCATION> genex causes the LOCATION property
to be accessed during generation. Calling CreateGenerationObjects
during generation blows away all the objects currently being used for
generation and is not safe. Add a condition to call it only when
configuration is not finished.
Rename Modules/Platform/<os>-<lang>.cmake files to
Modules/Platform/<os>-Determine-<lang>.cmake to clarify their role.
For compatibility with user-provided modules, load the old names
if they exist.
If e.g. libc.a is passed before any objects the linker raises the follwing
warning: cannot resolve archive libc.a to a compatible library, as no
input files have been encountered
In the end the library is skipped and missing symbols occur.
Signed-off-by: Alexander Stein <alexander.stein@systec-electronic.com>
Matthew Woehlke
Brad King
Kitware Robot
Daniel Pfeifer
Michał Górny
Clinton Stimpson
Orion Poplawski
Alex Turbov
Chuck Atkins
Alexander Stein
Matthäus G. Chajdas