CMake issueshttps://gitlab.kitware.com/cmake/cmake/-/issues2020-04-27T08:01:21-04:00https://gitlab.kitware.com/cmake/cmake/-/issues/17982Adding alias to non-global imported target fails silently2020-04-27T08:01:21-04:00Eugene ShalyginAdding alias to non-global imported target fails silentlycmake 3.11
Example:
`
add_library(l SHARED IMPORTED)
add_library(al ALIAS l)
if (TARGET al)
message(STATUS "al is target")
endif()
`
The alias target is not created, as it is expected from the documentation, but the `add_library(... AL...cmake 3.11
Example:
`
add_library(l SHARED IMPORTED)
add_library(al ALIAS l)
if (TARGET al)
message(STATUS "al is target")
endif()
`
The alias target is not created, as it is expected from the documentation, but the `add_library(... ALIAS ...)` call fails silently, and that is not desirable. Please make it print out a diagnostic message, as an attempt to alias an alias does.3.11.2Brad KingBrad Kinghttps://gitlab.kitware.com/cmake/cmake/-/issues/17985[regression 3.11] AUTORCC results in a CMP0058 warning when advertising a min...2018-05-15T09:58:59-04:00Peter Wupeter@lekensteyn.nl[regression 3.11] AUTORCC results in a CMP0058 warning when advertising a minimum version lower than CMake 3.3Starting with CMake 3.11, a project that has minimum CMake version 3.2 or earlier (but not CMake 3.3) using AUTORCC will complain:
```
CMake Warning (dev):
Policy CMP0058 is not set: Ninja requires custom command byproducts to be
exp...Starting with CMake 3.11, a project that has minimum CMake version 3.2 or earlier (but not CMake 3.3) using AUTORCC will complain:
```
CMake Warning (dev):
Policy CMP0058 is not set: Ninja requires custom command byproducts to be
explicit. Run "cmake --help-policy CMP0058" for policy details. Use the
cmake_policy command to set the policy and suppress this warning.
This project specifies custom command DEPENDS on files in the build tree
that are not specified as the OUTPUT or BYPRODUCTS of any
add_custom_command or add_custom_target:
CMakeFiles/ExampleOutput_autogen.dir/RCCexampleInfo.cmake
For compatibility with versions of CMake that did not have the BYPRODUCTS
option, CMake is generating phony rules for such files to convince 'ninja'
to build.
Project authors should add the missing BYPRODUCTS or OUTPUT options to the
custom commands that produce these files.
```
Additionally, said phony target is indeed visible in the build.ninja file (which is not present when using a larger minimum version).
This was bisected to v3.10.2-1009-ga8ee7406a (merged via !1735, authored by @sebholt).
To reproduce, take the following four files and simply build with `cmake -GNinja`.
CMakeLists.txt
```
cmake_minimum_required(VERSION 3.2)
project(CMakeQtExample)
find_package(Qt5 COMPONENTS Widgets REQUIRED)
set(CMAKE_AUTORCC ON)
add_executable(ExampleOutput main.cpp example.qrc)
target_link_libraries(ExampleOutput Qt5::Widgets)
```
main.cpp
```c
#include <QApplication>
int main(int argc, char *argv[]) {
QApplication app(argc, argv);
Q_INIT_RESOURCE(example);
return app.exec();
}
```
example.qrc
```
<RCC>
<qresource prefix="Example">
<file>Square.ico</file>
</qresource>
</RCC>
```
Square.ico is just a picture file.3.11.2Sebastian HoltermannSebastian Holtermannhttps://gitlab.kitware.com/cmake/cmake/-/issues/17993Empty argument in add_custom_command crashes when using single-configuration ...2018-05-15T09:54:12-04:00Yves FrederixEmpty argument in add_custom_command crashes when using single-configuration generator and COMMAND_EXPAND_LISTS is providedSee also MR !2073.
Consider the following `CMakeLists.txt`:
```
cmake_minimum_required(VERSION 3.9)
project(test CXX)
if(NOT EXISTS foo.cpp)
file(WRITE foo.cpp "")
endif()
add_library(foo STATIC foo.cpp)
add_custom_command(
# In ...See also MR !2073.
Consider the following `CMakeLists.txt`:
```
cmake_minimum_required(VERSION 3.9)
project(test CXX)
if(NOT EXISTS foo.cpp)
file(WRITE foo.cpp "")
endif()
add_library(foo STATIC foo.cpp)
add_custom_command(
# In real life, the empty string on the next line would be a generator expression that evaluates to the empty string for some configurations.
TARGET foo POST_BUILD COMMAND ""
COMMAND_EXPAND_LISTS
)
```
Use a single-configuration generator to configure and observe that CMake crashes somewhere in between the configuration and generation phase.
I had a closer look at the problem and the cause seems to lie in the constructor of `cmCustomCommandGenerator`. In case the command is empty and `COMMAND_EXPAND_LISTS` is unset, the empty string is added to the argument list. In case `COMMAND_EXPAND_LISTS` _is_ given, however, it is not. Later on in the code, the crash is caused when the first element of an empty vector is accessed (see `cmCustomCommandGenerator::GetArgv0Location`).
My fix was to mimick the behavior of the constructor for the case in which `COMMAND_EXPAND_LISTS` is absent, i.e., not removing empty arguments. To me, this made sense, as:
- the explicit absence of a `COMMAND` in `add_custom_command` is already considered a FATAL_ERROR. This, and the fact that the first element in the list is accessed later on, suggests to me that there is an invariant stating that there should always be a command, but it might be empty.
- I noticed the existence of a method `cmCustomCommandGenerator::HasOnlyEmptyCommandLines`, which suggests that custom commands, at least internally, are allowed to be empty.
it seems, however, that things might not be as simple as I initially thought as one of the reasons of being of `COMMAND_EXPAND_LISTS` was exactly to filter out the empty lines, so I would like to open a discussion on how to best fix the crash.3.11.2Brad KingBrad Kinghttps://gitlab.kitware.com/cmake/cmake/-/issues/17727warnings in InstallRequiredSystemLibraries.cmake with ifort 18 on Linux2018-05-14T10:59:58-04:00Janus Weilwarnings in InstallRequiredSystemLibraries.cmake with ifort 18 on LinuxThe issue I'm reporting here is very similar to #17550 and can be considered a follow-up ...
Similar to the Windows case reported earlier, I also see such warnings with ifort 18.0.1 on Linux (with a build of cmake's current git master):...The issue I'm reporting here is very similar to #17550 and can be considered a follow-up ...
Similar to the Windows case reported earlier, I also see such warnings with ifort 18.0.1 on Linux (with a build of cmake's current git master):
```
CMake Warning at /usr/local/share/cmake-3.11/Modules/InstallRequiredSystemLibraries.cmake:676 (message):
system runtime library file does not exist:
'/Intel/compilers_and_libraries_2018.1.163/linux/compiler/lib/intel64_lin/cilk_db.so'
CMake Warning at /usr/local/share/cmake-3.11/Modules/InstallRequiredSystemLibraries.cmake:676 (message):
system runtime library file does not exist:
'/Intel/compilers_and_libraries_2018.1.163/linux/compiler/lib/intel64_lin/libistrconv.so'
CMake Warning at /usr/local/share/cmake-3.11/Modules/InstallRequiredSystemLibraries.cmake:686 (message):
system runtime library file does not exist:
'/Intel/compilers_and_libraries_2018.1.163/linux/compiler/lib/intel64_lin/irml'
```
With cmake 10.2 I also see the following ...
```
CMake Warning at /usr/local/share/cmake-3.10/Modules/InstallRequiredSystemLibraries.cmake:670 (message):
system runtime library file does not exist:
'/Intel/compilers_and_libraries_2018.1.163/linux/compiler/lib/intel64_lin/libgfxoffload.so'
```
... but this one seems to be fixed by 7d1ed84ceaa1c3467c091de302c778b5989bd03c in 3.11.
As on Windows, I have only the Intel Fortran compiler installed, but not the Intel C++ compiler.3.11.2Christian PfeifferChristian Pfeifferhttps://gitlab.kitware.com/cmake/cmake/-/issues/17934FindBlas.cmake: (CMake 3.11) pkg-config variant populates BLAS_LIBRARIES with...2018-05-11T13:35:21-04:00Matthias MaierFindBlas.cmake: (CMake 3.11) pkg-config variant populates BLAS_LIBRARIES with magic target string instead of actual librariesCommit a9c42e3ec09fa9cdf308344d12b0cc8c2e44d905 introduces a call to pkg-conf and populates, if successful the `BLAS_LIBRARIES` variable with `PkgConfig::PKGC_BLAS`. While this works fine for usage with `target_link_libraries`, or simila...Commit a9c42e3ec09fa9cdf308344d12b0cc8c2e44d905 introduces a call to pkg-conf and populates, if successful the `BLAS_LIBRARIES` variable with `PkgConfig::PKGC_BLAS`. While this works fine for usage with `target_link_libraries`, or similar, this has a number of severe issues:
- Projects might expect that `BLAS_LIBRARIES` is actually a semicolon separated list of actual libraries (for example for creating non-cmake configuration, or similar). It is not advisable to change the behavior of a bundled find module that drastically.
- This breaks the target export mechanism.
Minimal example for the export problem:
```
cmake_minimum_required(VERSION 3.11)
find_package(BLAS)
add_library(foo SHARED foo.cc)
target_link_libraries(foo ${BLAS_LIBRARIES})
export(TARGETS foo FILE ${CMAKE_BINARY_DIR}/ExportTargets.cmake)
```
Now, simply importing said `ExportTargets.cmake` fails:
```
cmake_minimum_required(VERSION 3.11)
include(.../ExportTargets.cmake)
add_library(bar SHARED bar.cc)
target_link_libraries(bar foo)
```
```
$ cmake .
CMake Error at CMakeLists.txt:4 (ADD_LIBRARY):
Target "bar" links to target "PkgConfig::PKGC_BLAS" but the target was not
found. Perhaps a find_package() call is missing for an IMPORTED target, or
an ALIAS target is missing?
$ make
ld: cannot find -lPkgConfig::PKGC_BLAS
```
```3.11.2Rolf Eike BeerRolf Eike Beerhttps://gitlab.kitware.com/cmake/cmake/-/issues/17970Wrong python library gets linked against when finding boost library `numpy3`.2018-05-11T09:17:11-04:00Urbain VaesWrong python library gets linked against when finding boost library `numpy3`.I recently updated CMake from 3.10 to 3.11.1 on my arch machine.
Previously, a configuration file of the type
```
set(CMAKE_VERBOSE_MAKEFILE ON)
find_package(PythonLibs 3 REQUIRED)
find_package(Boost COMPONENTS python3 COMPONENTS ...I recently updated CMake from 3.10 to 3.11.1 on my arch machine.
Previously, a configuration file of the type
```
set(CMAKE_VERBOSE_MAKEFILE ON)
find_package(PythonLibs 3 REQUIRED)
find_package(Boost COMPONENTS python3 COMPONENTS numpy3 REQUIRED)
add_executable (test test.cpp)
target_link_libraries(test ${Boost_LIBRARIES} ${PYTHON_LIBRARIES})
```
would be lead to CMake linking my program against 2 boost libraries: `python3` and `numpy3`.
Since the update, 3 libraries are being linked against, one of which seeminly corresponding to a different version of python.
Now,
```
-- Boost version: 1.66.0
-- Found the following Boost libraries:
-- python3
-- numpy3
-- python
```
Before,
```
-- Boost version: 1.66.0
-- Found the following Boost libraries:
-- python3
-- numpy3
```
This results in a linking error in a build script that I use,
and I also observe that error with the following minimal example, (`test.cpp`)
```
#include <iostream>
using namespace std;
int main()
{
cout << "Hello, world!" << endl;
}
```
In addition, if I replace the line with just
```
find_package(Boost COMPONENTS numpy3 REQUIRED)
```
the wrong version of python gets linked against instead of python3.
Is there a new way of linking against boost numpy?
Thank you!3.11.2Roger LeighRoger Leighhttps://gitlab.kitware.com/cmake/cmake/-/issues/17892FindBoost.cmake Boost 1.66 and Numpy Dependencies2018-05-11T09:17:08-04:00David FreeseFindBoost.cmake Boost 1.66 and Numpy DependenciesI'm running Boost 1.66 compiled with only Python3 support. A simplified version of the cmake file I am currently using is as follows:
find_package(PythonInterp 3 REQUIRED)
find_package(PythonLibs 3 REQUIRED)
find_package(Bo...I'm running Boost 1.66 compiled with only Python3 support. A simplified version of the cmake file I am currently using is as follows:
find_package(PythonInterp 3 REQUIRED)
find_package(PythonLibs 3 REQUIRED)
find_package(Boost REQUIRED python3 numpy3)
python_add_module(recon python.cpp)
target_link_libraries(recon PUBLIC Boost::python3 Boost::numpy3 ${PYTHON_LIBRARIES})
target_include_directories(recon PUBLIC ${PYTHON_INCLUDE_DIRS})
I get the error:
> Target "recon" links to target "Boost::python" but the target was not
> found. Perhaps a find_package() call is missing for an IMPORTED target, or
> an ALIAS target is missing?
It appears from 1673923c that 1.66 is grouped with 1.65 in that python should be linked as a dependency for NumPy, not python3. This is consistent with running BoostScanDeps.cmake on Boost 1.66, but seems to fail in my case. It seems odd to need the "python" dependency, as the following will fail for me, as I haven't built against python2:
find_package(Boost REQUIRED python)
Is there perhaps something I'm doing wrong, or is BoostScanDeps perhaps getting the wrong things for 1.66?3.11.2Roger LeighRoger Leighhttps://gitlab.kitware.com/cmake/cmake/-/issues/17965FindCUDA: broken separable compilation when cublas is not added to the target2018-05-11T07:33:30-04:00Jakub KlinkovskýFindCUDA: broken separable compilation when cublas is not added to the targetThe changes done in !1446 are completely wrong as they break compilation of targets which don't link to CUBLAS. Counter-example and build log are attached.
[build.log](/uploads/8769eba921d92c5fc7448f4637984d50/build.log)
[cuda-test.tar]...The changes done in !1446 are completely wrong as they break compilation of targets which don't link to CUBLAS. Counter-example and build log are attached.
[build.log](/uploads/8769eba921d92c5fc7448f4637984d50/build.log)
[cuda-test.tar](/uploads/382d260025452ed79dfee7168e1e4689/cuda-test.tar)3.11.2Brad KingBrad Kinghttps://gitlab.kitware.com/cmake/cmake/-/issues/17941CMake 3.11.1: CTest starts children with non-blocking pipes on Linux/sparc642018-05-03T08:13:20-04:00John Paul Adrian GlaubitzCMake 3.11.1: CTest starts children with non-blocking pipes on Linux/sparc64The tests WarnUnusedUnusedViaSet and WarnUnusedUnusedViaUnset are failing with cmake 3.11.1:
```
99% tests passed, 2 tests failed out of 488
Label Time Summary:
Label1 = 0.63 sec*proc (1 test)
Label2 = 0.63 sec*proc (1 test)
...The tests WarnUnusedUnusedViaSet and WarnUnusedUnusedViaUnset are failing with cmake 3.11.1:
```
99% tests passed, 2 tests failed out of 488
Label Time Summary:
Label1 = 0.63 sec*proc (1 test)
Label2 = 0.63 sec*proc (1 test)
Total Test time (real) = 3814.47 sec
The following tests FAILED:
178 - WarnUnusedUnusedViaSet (Failed)
179 - WarnUnusedUnusedViaUnset (Failed)
Errors while running CTest
```
The kernel dmesg shows:
```
[844933.149371] cmsysTestProces[23903]: segfault at 4 ip 00000100000027d4 (rpc 00000100000027c0) sp 000007feffc900d1 error 1 in cmsysTestProcess[10000000000+a000]
[844933.153765] cmsysTestProces[23909]: segfault at 4 ip 00000100000027d4 (rpc 00000100000027c0) sp 000007feff86a0d1 error 1 in cmsysTestProcess[10000000000+a000]
```
They previously passed without problems in 3.10.2:
```
174/454 Test #181: WarnUnusedUnusedViaUnset ............................... Passed 7.01 sec
181/454 Test #180: WarnUnusedUnusedViaSet ................................. Passed 7.75 sec
```
Full build logs for 3.11.1 and 3.10.2 available in [1] and [2].
Let me know if need access to a sparc64 porterbox for testing or anything else.
Since other architectures are not affected by this issue, this is most likely related to unaligned access to which SPARC is generally very sensitive to.
[1]: https://buildd.debian.org/status/fetch.php?pkg=cmake&arch=sparc64&ver=3.11.1-1&stamp=1524657305&raw=0
[2]: https://buildd.debian.org/status/fetch.php?pkg=cmake&arch=sparc64&ver=3.10.2-1&stamp=1518958714&raw=03.11.2Brad KingBrad Kinghttps://gitlab.kitware.com/cmake/cmake/-/issues/17947Can not build cmake 3.10 or newer on MacOSX with XCode 8.0 and -mmacosx-versi...2018-04-30T09:21:21-04:00Mario EmmenlauerCan not build cmake 3.10 or newer on MacOSX with XCode 8.0 and -mmacosx-version-min=10.11I build cmake on MacOSX with ``CFLAGS`` set to ``-march=core2 -mmacosx-version-min=10.11``. This worked well up until 3.9.x, but starts to fail with 3.10 and newer. The error message is when cmake bootstraps itself:
```
The C++ compiler ...I build cmake on MacOSX with ``CFLAGS`` set to ``-march=core2 -mmacosx-version-min=10.11``. This worked well up until 3.9.x, but starts to fail with 3.10 and newer. The error message is when cmake bootstraps itself:
```
The C++ compiler does not support C++11
```
As far as I can see this should be wrong, because ``XCode 8.0`` ships ``AppleClang 8.0.0`` that is based on ``clang 3.9``, and clang has full ``c++11`` support since around version ``3.3``.
Am I doing something wrong? Is this a cmake issue, or is maybe the flag ``-mmacosx-version-min=10.11`` causing trouble? The build seems to work when I first build ``cmake 3.9`` and then use that to bootstrap ``cmake 3.11``.
I could find a related commit https://gitlab.kitware.com/cmake/cmake/commit/fd4fd9a276126a1b1044d57a064c3b8201a91a33 in case that helps?3.11.2Brad KingBrad Kinghttps://gitlab.kitware.com/cmake/cmake/-/issues/17850CMake 3.10.3 bootstrap fails on PPC Mac OS X 10.4.11, Tiger, because a warnin...2018-04-30T09:21:19-04:00Peter DyballaCMake 3.10.3 bootstrap fails on PPC Mac OS X 10.4.11, Tiger, because a warning is emitted?``
CMake Error at CMakeLists.txt:79 (message):
The C++ compiler does not support C++11 (e.g. std::unique_ptr).
-- Configuring incomplete, errors occurred!
`
is the symptom. CMakeError-log contains:
```
Run Build Command:"/opt/local/...``
CMake Error at CMakeLists.txt:79 (message):
The C++ compiler does not support C++11 (e.g. std::unique_ptr).
-- Configuring incomplete, errors occurred!
`
is the symptom. CMakeError-log contains:
```
Run Build Command:"/opt/local/bin/gmake" "cmTC_ddb80/fast"
gmake -f CMakeFiles/cmTC_ddb80.dir/build.make CMakeFiles/cmTC_ddb80.dir/build
gmake[1]: Entering directory '/opt/local/var/macports/build/_opt_local_var_macports_sources_lil.fr.rsync.macports.org_release_tarballs_ports_devel_cmake/cmake/work/cmake-3.10.3/CMakeFiles/CMakeTmp'
Building CXX object CMakeFiles/cmTC_ddb80.dir/cm_cxx_unique_ptr.cxx.o
/opt/local/bin/g++-mp-6 -pipe -Os -D_GLIBCXX_USE_CXX11_ABI=0 -m32 -isysroot /Developer/SDKs/MacOSX10.4u.sdk -mmacosx-version-min=10.4 -std=gnu++14 -o CMakeFiles/cmTC_ddb80.dir/cm_cxx_unique_ptr.cxx.o -c /opt/local/var/macports/build/_opt_local_var_macports_sources_lil.fr.rsync.macports.org_release_tarballs_ports_devel_cmake/cmake/work/cmake-3.10.3/Source/Checks/cm_cxx_unique_ptr.cxx
Linking CXX executable cmTC_ddb80
/opt/local/var/macports/build/_opt_local_var_macports_sources_lil.fr.rsync.macports.org_release_tarballs_ports_devel_cmake/cmake/work/cmake-3.10.3/Bootstrap.cmk/cmake -E cmake_link_script CMakeFiles/cmTC_ddb80.dir/link.txt --verbose=1
/opt/local/bin/g++-mp-6 -pipe -Os -D_GLIBCXX_USE_CXX11_ABI=0 -m32 -isysroot /Developer/SDKs/MacOSX10.4u.sdk -mmacosx-version-min=10.4 -Wl,-search_paths_first -Wl,-headerpad_max_install_names -L/opt/local/lib -Wl,-headerpad_max_install_names -t CMakeFiles/cmTC_ddb80.dir/cm_cxx_unique_ptr.cxx.o -o cmTC_ddb80
/Developer/SDKs/MacOSX10.4u.sdk/usr/lib/crt1.o
/opt/local/lib/gcc6/gcc/ppc-apple-darwin8/6.4.0/crt3.o
CMakeFiles/cmTC_ddb80.dir/cm_cxx_unique_ptr.cxx.o
/opt/local/lib/gcc6/libstdc++.dylib
/Developer/SDKs/MacOSX10.4u.sdk/usr/lib/libgcc_s.10.4.dylib
/opt/local/lib/gcc6/libgcc_ext.10.4.dylib
/opt/local/lib/gcc6/gcc/ppc-apple-darwin8/6.4.0/libgcc.a
/Developer/SDKs/MacOSX10.4u.sdk/usr/lib/libSystemStubs.a
/Developer/SDKs/MacOSX10.4u.sdk/usr/lib/libSystem.dylib
/Developer/SDKs/MacOSX10.4u.sdk/usr/lib/system/libmathCommon.A.dylib
/Developer/SDKs/MacOSX10.4u.sdk/opt/local/lib/gcc6/gcc/ppc-apple-darwin8/6.4.0/libgcc.a(darwin-gpsave.old: warning: object file compiled with -mlong-branch which is no longer needed. To remove this warning, recompile without -mlong-branch: /opt/local/lib/gcc6/gcc/ppc-apple-darwin8/6.4.0/crt3.o
)
gmake[1]: Leaving directory '/opt/local/var/macports/build/_opt_local_var_macports_sources_lil.fr.rsync.macports.org_release_tarballs_ports_devel_cmake/cmake/work/cmake-3.10.3/CMakeFiles/CMakeTmp'
`
When I perform the compilation steps manually, no error is emitted, $status of each step is exactly 0 (zero). Is the bootstrap process fooled by the warning?
--
Greetings
Pete3.11.2Brad KingBrad Kinghttps://gitlab.kitware.com/cmake/cmake/-/issues/17942Ninja: file(GENERATE) outputs always considered dirty2018-04-26T08:48:50-04:00Brad KingNinja: file(GENERATE) outputs always considered dirtyThe code
```cmake
file(GENERATE
OUTPUT ${CMAKE_CURRENT_BINARY_DIR}/foo.c
CONTENT [[int main() { return 0; }]]
)
add_executable(foo ${CMAKE_CURRENT_BINARY_DIR}/foo.c)
```
causes ninja to do the following after the first build:
``...The code
```cmake
file(GENERATE
OUTPUT ${CMAKE_CURRENT_BINARY_DIR}/foo.c
CONTENT [[int main() { return 0; }]]
)
add_executable(foo ${CMAKE_CURRENT_BINARY_DIR}/foo.c)
```
causes ninja to do the following after the first build:
```console
$ ninja -d explain
ninja explain: output cmake_object_order_depends_target_foo of phony edge with no inputs doesn't exist
ninja explain: cmake_object_order_depends_target_foo is dirty
ninja explain: foo.c is dirty
ninja explain: foo.c is dirty
ninja explain: CMakeFiles/foo.dir/foo.c.o is dirty
ninja explain: foo is dirty
[1/3]
```3.11.2Brad KingBrad Kinghttps://gitlab.kitware.com/cmake/cmake/-/issues/17938FindJava.cmake: handle new openjdk versioning2018-04-26T08:24:44-04:00Tiago DaitxFindJava.cmake: handle new openjdk versioningThe fix for #17613 (merge !1637) does not take into account [JEP-223](http://openjdk.java.net/jeps/223) where the java versioning changed from the "1.VV" format to "VV".
The right way to compare versions should be to replace the current...The fix for #17613 (merge !1637) does not take into account [JEP-223](http://openjdk.java.net/jeps/223) where the java versioning changed from the "1.VV" format to "VV".
The right way to compare versions should be to replace the current `Java_VERSION VERSION_LESS "1.10"` with `Java_VERSION VERSION_LESS "10"`.3.11.2Marc ChevrierMarc Chevrierhttps://gitlab.kitware.com/cmake/cmake/-/issues/17933UseJava fails when activating CMAKE_DISABLE_SOURCE_CHANGES (since 3.11 only)2018-04-25T08:57:12-04:00Martin QuinsonUseJava fails when activating CMAKE_DISABLE_SOURCE_CHANGES (since 3.11 only)Hello,
when passing -DCMAKE_DISABLE_SOURCE_CHANGES=on to our project, it fails with the following error message:
```
14:24:47 CMake Error at /usr/share/cmake/Modules/UseJava.cmake:514 (file):
14:24:47 file attempted to create a direc...Hello,
when passing -DCMAKE_DISABLE_SOURCE_CHANGES=on to our project, it fails with the following error message:
```
14:24:47 CMake Error at /usr/share/cmake/Modules/UseJava.cmake:514 (file):
14:24:47 file attempted to create a directory:
14:24:47 /builds/workspace/SimGrid-Multi/build_mode/Debug/node/simgrid-fedora-rawhide-64/build/SimGrid-3.19.90/build
14:24:47 into a source directory.
14:24:47 Call Stack (most recent call first):
14:24:47 tools/cmake/Java.cmake:64 (add_jar)
14:24:47 CMakeLists.txt:888 (include)
```
This is caused by https://github.com/Kitware/CMake/blob/master/Modules/UseJava.cmake#L514:
```
# ensure output directory exists
file (MAKE_DIRECTORY "${_add_jar_OUTPUT_DIR}")
```
My code calling this macro is the following https://github.com/simgrid/simgrid/blob/master/tools/cmake/Java.cmake#L64:
```
add_jar(simgrid-java_jar ${JMSG_JAVA_SRC} OUTPUT_NAME simgrid)
```
I have traced the execution of my cmake, and it takes this path https://github.com/Kitware/CMake/blob/master/Modules/UseJava.cmake#L509
```
set(_add_jar_OUTPUT_DIR ${CMAKE_CURRENT_BINARY_DIR})
```
So, UseJava is trying to create the directory CMAKE_CURRENT_BINARY_DIR, and this is detected as an error. This seems to be a cmake bug since my build is actually out of dir. The full log is available here: https://ci.inria.fr/simgrid/job/SimGrid-Multi/build_mode=Debug,node=simgrid-fedora-rawhide-64/5454/console (that log is a bit complex to read because we checkout the code, build an archive our of it (triggering a cmake run), unpack the archive elsewhere and then do an out-of-tree build on what we unpacked from the archive).
In my setting, the source is unpacked into /builds/workspace/SimGrid-Multi/build_mode/Debug/node/simgrid-fedora-rawhide-64/build/SimGrid-3.19.90 and the build dir is /builds/workspace/SimGrid-Multi/build_mode/Debug/node/simgrid-fedora-rawhide-64/build/SimGrid-3.19.90/build, which is CMAKE_SOURCE_DIR/build.
The jar is build in my root directory, and I think this is the problem: ${_add_jar_OUTPUT_DIR} is ${CMAKE_CURRENT_BINARY_DIR}, which is ${CMAKE_SOURCE_DIR}/build. So at the end, this directory IS in the source directory. But since that's also the root of the build dir, I think that this behavior should still be allowed.
Finally, this error only seem to occur on CMake 3.11. On other slaves, I have CMake 3.10, or CMake 3.9, and they all work like a charm with the exact same building conditions on my side.
Thanks for cmake, that's a great piece of software.
Mt.3.11.2Marc ChevrierMarc Chevrierhttps://gitlab.kitware.com/cmake/cmake/-/issues/17913InstallRequiredSystemLibraries.cmake tries to install non-existent MFC DLL on...2018-04-19T08:24:44-04:00Christof KrügerInstallRequiredSystemLibraries.cmake tries to install non-existent MFC DLL on Visual Studio 2017Hi,
InstallRequiredSystemLibraries.cmake gives the following warning when CMAKE_INSTALL_MFC_LIBRARIES is set. I'm using Visual Studio 15.6.3.
```
1> CMake Warning at C:/Program Files (x86)/Microsoft Visual Studio/2017/Professional/Comm...Hi,
InstallRequiredSystemLibraries.cmake gives the following warning when CMAKE_INSTALL_MFC_LIBRARIES is set. I'm using Visual Studio 15.6.3.
```
1> CMake Warning at C:/Program Files (x86)/Microsoft Visual Studio/2017/Professional/Common7/IDE/CommonExtensions/Microsoft/CMake/CMake/share/cmake-3.10/Modules/InstallRequiredSystemLibraries.cmake:567 (message):
1> system runtime library file does not exist: 'C:/Program Files
1> (x86)/Microsoft Visual
1> Studio/2017/Professional/VC/Redist/MSVC/14.13.26020/Debug_NonRedist/x86/Microsoft.VC141.DebugMFC/mfcm140d.dll'
1> Call Stack (most recent call first):
1> _dep/bb/core/build/bb_install_runtime_dlls.cmake(8): (include)
1> CMakeLists.txt(66): (bb_install_runtime_dlls)
1>
1>
1> MFC: C:/Program Files (x86)/Microsoft Visual Studio/2017/Professional/VC/Redist/MSVC/14.13.26020/x86/Microsoft.VC141.MFC
```
The directory `C:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\VC\Redist\MSVC\14.13.26020\debug_nonredist\x86\Microsoft.VC141.DebugMFC` contains the following files only:
* mfc140d.dll
* mfc140ud.dll
* mfcm140ud.dll
Apparently, there is a check in the current implementation whether `${MSVC_MFC_DIR}/mfc${v}d.dll` exists and it is assumed that `${MSVC_MFC_DIR}/mfcm${v}d.dll` also exists (which is not the case).3.11.2