Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

cmake_* tests don't use the build system's compiler #1747

Closed
Tridacnid opened this issue Sep 11, 2019 · 5 comments · Fixed by #1844
Closed

cmake_* tests don't use the build system's compiler #1747

Tridacnid opened this issue Sep 11, 2019 · 5 comments · Fixed by #1844
Assignees
Labels
release item: 🔨 further change solution: proposed fix a fix for the issue has been proposed and waits for confirmation
Milestone

Comments

@Tridacnid
Copy link
Contributor

When building I set the compiler with the -DCMAKE_<LANG>_COMPILER=<path> option. Some tests generate new projects with CMake but don't make use of the compiler that I want CMake to use. I suspect that this isn't an issue for people who use the CC/CXX enviroment variables (or any equivalent on non-Linux systems).

Steps to reproduce:

  1. Have a Linux environment that by default only has an unsupported compiler. I use CentOS6, which has GCC 4.4.7 by default.
  2. Install a compiler toolchain in a non-PATH location. I use the devtoolset-8 package from the SCLo RPM stream which provides a GCC 8.2.1 based toolchain located at /opt/rh/devtoolset-8/root/usr/bin/{gcc,g++}
  3. Download the source code and try to build it, setting the C++ and C compilers with -DCMAKE_CXX_COMPILER=<path to g++> and -DCMAKE_C_COMPILER=<path to gcc>
  4. Compile project
  5. Run test with CTest. The tests that create new CMake projects should fail because they will pick up the system GCC (4.4.7).

A patch I made and tried on my Cent6 environment:

diff --git a/test/cmake_add_subdirectory/CMakeLists.txt b/test/cmake_add_subdirectory/CMakeLists.txt
index ad04547e7d1c3943781a7e119c7372eaf74a1274..6126033de59ab0b2d0b683ec7485c8932a07c94c 100644
--- a/test/cmake_add_subdirectory/CMakeLists.txt
+++ b/test/cmake_add_subdirectory/CMakeLists.txt
@@ -3,6 +3,8 @@ add_test(NAME cmake_add_subdirectory_configure
     -G "${CMAKE_GENERATOR}"
     -Dnlohmann_json_source=${PROJECT_SOURCE_DIR}
     ${CMAKE_CURRENT_SOURCE_DIR}/project
+    -DCMAKE_CXX_COMPILER=${CMAKE_CXX_COMPILER}
+    -DCMAKE_C_COMPILER=${CMAKE_C_COMPILER}
 )
 add_test(NAME cmake_add_subdirectory_build
   COMMAND ${CMAKE_COMMAND} --build .
diff --git a/test/cmake_import/CMakeLists.txt b/test/cmake_import/CMakeLists.txt
index 911c342c6ded16a057d16480e9a7c05eafb0cd23..ec660378cdfccbbc8a79f9b02df1ad09e529f2b4 100644
--- a/test/cmake_import/CMakeLists.txt
+++ b/test/cmake_import/CMakeLists.txt
@@ -3,6 +3,8 @@ add_test(NAME cmake_import_configure
     -G "${CMAKE_GENERATOR}"
     -Dnlohmann_json_DIR=${PROJECT_BINARY_DIR}
     ${CMAKE_CURRENT_SOURCE_DIR}/project
+    -DCMAKE_CXX_COMPILER=${CMAKE_CXX_COMPILER}
+    -DCMAKE_C_COMPILER=${CMAKE_C_COMPILER}
 )
 add_test(NAME cmake_import_build
   COMMAND ${CMAKE_COMMAND} --build .
diff --git a/test/cmake_import_minver/CMakeLists.txt b/test/cmake_import_minver/CMakeLists.txt
index 8cef2fabb4c29198bf6791a0f86dc1a11cf6d7f8..eb7e6906d513dd3ba868d6ffb1d8aa294959bc6a 100644
--- a/test/cmake_import_minver/CMakeLists.txt
+++ b/test/cmake_import_minver/CMakeLists.txt
@@ -3,6 +3,8 @@ add_test(NAME cmake_import_minver_configure
     -G "${CMAKE_GENERATOR}"
     -Dnlohmann_json_DIR=${PROJECT_BINARY_DIR}
     ${CMAKE_CURRENT_SOURCE_DIR}/project
+    -DCMAKE_CXX_COMPILER=${CMAKE_CXX_COMPILER}
+    -DCMAKE_C_COMPILER=${CMAKE_C_COMPILER}
 )
 add_test(NAME cmake_import_minver_build
   COMMAND ${CMAKE_COMMAND} --build .

I get unrelated failures referencing "issue #186 miloyip/nativejson-benchmark: floating-point parsing" but I will explore those in a separate issue if appropriate.

@stale
Copy link

stale bot commented Oct 11, 2019

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

@stale stale bot added the state: stale the issue has not been updated in a while and will be closed automatically soon unless it is updated label Oct 11, 2019
@Tridacnid
Copy link
Contributor Author

Bad bot

@stale stale bot removed the state: stale the issue has not been updated in a while and will be closed automatically soon unless it is updated label Oct 13, 2019
@t-b
Copy link
Contributor

t-b commented Oct 13, 2019

@Tridacnid Why not post your patch as a PR?

@stale
Copy link

stale bot commented Nov 12, 2019

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

@stale stale bot added the state: stale the issue has not been updated in a while and will be closed automatically soon unless it is updated label Nov 12, 2019
@Tridacnid
Copy link
Contributor Author

Agh, stop. I'm doing that patch, promise.

@stale stale bot removed the state: stale the issue has not been updated in a while and will be closed automatically soon unless it is updated label Nov 12, 2019
Tridacnid added a commit to Tridacnid/json that referenced this issue Nov 19, 2019
@nlohmann nlohmann self-assigned this Nov 19, 2019
@nlohmann nlohmann added release item: 🔨 further change solution: proposed fix a fix for the issue has been proposed and waits for confirmation labels Nov 19, 2019
@nlohmann nlohmann added this to the Release 3.7.4 milestone Nov 19, 2019
OmnipotentEntity pushed a commit to OmnipotentEntity/json that referenced this issue Mar 27, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
release item: 🔨 further change solution: proposed fix a fix for the issue has been proposed and waits for confirmation
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants