This should be assigned to kde@. cmake is not able to deal with spaces in CMAKE_C_COMPILER and CMAKE_CXX_COMPILER. Example print/scribus: ===> Configuring for scribus-1.3.3.14_1 /bin/mkdir -p /usr/obj/mobileKamikaze.norad/amd64/usr/ports/print/scribus/work/scribus-1.3.3.14 -- The C compiler identification is unknown -- The CXX compiler identification is unknown -- Check for working C compiler: env CCACHE_PREFIX=/usr/local/bin/distcc /usr/local/bin/ccache cc CMake Error: your C compiler: "env CCACHE_PREFIX=/usr/local/bin/distcc /usr/local/bin/ccache cc" was not found. Please set CMAKE_C_COMPILER to a valid compiler path or name. CMake Error: Internal CMake error, TryCompile configure of cmake failed -- Check for working C compiler: env CCACHE_PREFIX=/usr/local/bin/distcc /usr/local/bin/ccache cc -- broken CMake Error at /usr/local/share/cmake/Modules/CMakeTestCCompiler.cmake:52 (MESSAGE): The C compiler "env CCACHE_PREFIX=/usr/local/bin/distcc /usr/local/bin/ccache cc" is not able to compile a simple test program. It fails with the following output: .. This is from the CMakeCache.txt file: //CXX compiler. CMAKE_CXX_COMPILER:FILEPATH=env CCACHE_PREFIX=/usr/local/bin/distcc /usr/local/bin/ccache c++ .. //C compiler. CMAKE_C_COMPILER:FILEPATH=env CCACHE_PREFIX=/usr/local/bin/distcc /usr/local/bin/ccache cc Fix: cmake is able to handle CC with spaces if it's passed on through the environment instead of using parameters. From the CMakeCache.txt file in that case: //C compiler. CMAKE_C_COMPILER:FILEPATH=/usr/bin/env //First argument to C compiler CMAKE_C_COMPILER_ARG1:STRING= CCACHE_PREFIX=/usr/local/bin/distcc /usr/local/bin/ccache cc Give me a list of ports to test it on and I'll provide you with tinderbox logs. Patch attached with submission follows: How-To-Repeat: Just define CC containing spaces and try to build a port with cmake (e.g. print/scribus or devel/qmake4).
Responsible Changed From-To: freebsd-ports-bugs->kde Fix synopsis and assign.
Just a warning in advance, I have created 4 tinderbuilds to each of which I have queued all 315 ports with USE_CMAKE in the Makefile. The builds have the following configurations: 1. Regular ports tree, CC=cc \ Check for 2. Patched ports tree, CC=cc / regressions 3. Regular ports tree, CC="env cc" \ Check for patch 4. Patched ports tree, CC="env cc" / effectiveness I expect this will take a couple of days, it's a couple of thousand packages to build. I will present the results in a 4*n matrix, once the builds have completed. Regards -- A: Because it fouls the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail?
After running into some issues with tinderd I added MP safe locking, applied the patch in ports/158722 to the ports trees, because gobject-introspection was such a PITA and started over. Currently 848 of 1260 queue entries have been processed. So far two regressions manifested: games/opensonic graphics/rawtherapee I have attached patches for both. So far exactly 100 cases have improved due to the cmake patch. -- A: Because it fouls the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail?
I think the results speak for themselves. I dedicated my box to this for more than 9 days, 1260 queue entries were processed. I hope there'll be some kind of reaction. Will take care of devel/kdebindings4-ruby after I get some sleep. I've been up for > 30 hours. I've got a patch for OpenCV, too. I'll handle it directly with Martin if this gets a commit. -- A: Because it fouls the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail?
This is my second go, this time a complete patch set, nothing stale, no regressions. Tinderbox results are attached as well. -- A: Because it fouls the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail?
The longer this is delayed, the more patches I will have to change. Regards, Kami
State Changed From-To: open->closed this is fixed since ages.
This has never been fixed: ===> Configuring for llvm37-3.7.1_2 ===> Performing out-of-source build /bin/mkdir -p /wrkdirs/usr/ports/devel/llvm37/work/.build -- The C compiler identification is unknown -- The CXX compiler identification is unknown CMake Error at CMakeLists.txt:29 (project): The CMAKE_C_COMPILER: /usr/bin/env cc is not a full path to an existing compiler tool. Tell CMake where to find the compiler by setting either the environment variable "CC" or the CMake cache entry CMAKE_C_COMPILER to the full path to the compiler, or to the compiler name if it is in the PATH.
I'm taking this, expect a differential within the week.
If this really is an issue it should be a bug report for cmake upstream and not fixed in the ports tree for each cmake using port, no? So, given that this has existed since 2011...
Works when specifying the compiler through the environment. In a sample project, both of these build lines work: CC=cc cmake .. && make VERBOSE=1 CC="/usr/bin/env THIS=THAT /usr/bin/cc" cmake .. && make VERBOSE=1 The CMake output for the latter is a little weird, -- Check for working C compiler: /usr/bin/env -- works but not wrong. The OP notes this, as well. Current CMake even tells you, if you try to use the command-line-definition approach, what is wrong: cmake .. "-DCMAKE_C_COMPILER=/usr/bin/env THIS=THAT /usr/bin/cc" -- The C compiler identification is unknown CMake Error at CMakeLists.txt:2 (project): The CMAKE_C_COMPILER: /usr/bin/env THIS=THAT /usr/bin/cc is not a full path to an existing compiler tool. Tell CMake where to find the compiler by setting either the environment variable "CC" or the CMake cache entry CMAKE_C_COMPILER to the full path to the compiler, or to the compiler name if it is in the PATH. This should be, as tcberner@ points out, picked up upstream, or filed under "Don't Do That Then".
Discussed upstream in https://gitlab.kitware.com/cmake/cmake/issues/17346 Most of these patches are not for kde@ ports. They could be (re-)filed against the applicable ports. As tcberner@ points out, they have been sitting for a long time, and many no longer apply. From the kde@ side, the patch to move setting-CC to the environment instead of in the command-line arguments makes some sense. Both science/.kst2 and x11/qimageblitz have "bad" CMakeLists.txt that assume the C++ compiler is a single word. Those patches could apply, too.
The discussion upstream comes down to: - use the environment - use the applicable wrapper for distcc and similar See https://gitlab.kitware.com/cmake/cmake/issues/17346