$<COMPILE_LANG_AND_ID:lang,id> may only be used with binary targets

[emmenlau]

I'm building folly v2020.07.13.00 on Ubuntu 18.04 x86_64 with the standard system gcc but a newer cmake 3.18.0. On configure, I get the cmake error:

[...]
 -- Found gmock via config, defines=, include=/data/Debug/include, libs=GTest::gmock_main;GTest::gmock;GTest::gtest
 -- Found GTest: /data/Debug/lib/libgtest.a  
 -- Configuring done
 CMake Error at CMakeLists.txt:446 (file):
   Error evaluating generator expression:
     $<COMPILE_LANG_AND_ID:CUDA,NVIDIA>
   $<COMPILE_LANG_AND_ID:lang,id> may only be used with binary targets to
   specify include directories, compile definitions, and compile options.  It
   may not be used with the add_custom_command, add_custom_target, or
   file(GENERATE) commands.
 CMake Error at CMakeLists.txt:446 (file):
   Error evaluating generator expression:
     $<COMPILE_LANG_AND_ID:CUDA,NVIDIA>
   $<COMPILE_LANG_AND_ID:lang,id> may only be used with binary targets to
   specify include directories, compile definitions, and compile options.  It
   may not be used with the add_custom_command, add_custom_target, or
   file(GENERATE) commands.
 -- Generating done

cmake ends in error after that. I googled for this problem but could not find anything really useful. Also I can not find the lines $<COMPILE_LANG_AND_ID:CUDA,NVIDIA> in folly so I'm slightly confused where the problem originates from. Can someone point me in the right direction please?

[smazurov]

Ran into the same issue, downgrade to 3.17.3 resolved it.

[emmenlau]

Ran into the same issue, downgrade to 3.17.3 resolved it.

That is good to know. But actually I can even see the commit id of cmake that introduced this change (https://gitlab.kitware.com/ChrisTX/cmake/commit/e214abdaab4f8097095a601067b4071194ad01a5), and it seems this is the new default. The project needs to be updated sooner or later, or it will continue to fail with newer cmake.

[emmenlau]

@smazurov do you happen to know in which CMakeLists.txt it fails? I could not find the string COMPILE_LANG_AND_ID:CUDA in the project anywhere...

[smazurov]

@emmenlau no, my error was very similar except it was line 443, my guess is its one of the global dependencies that get installed on the system.

[adriaandegroot]

Line numbers vary a bit depending on distro patching, on FreeBSD with CMake 3.18 and folly 2020.07.27.00 we get this error message:

-- Configuring done
CMake Error at CMakeLists.txt:445 (file):
  Error evaluating generator expression:

    $<COMPILE_LANG_AND_ID:CUDA,NVIDIA>

  $<COMPILE_LANG_AND_ID:lang,id> may only be used with binary targets to
  specify include directories, compile definitions, and compile options.  It
  may not be used with the add_custom_command, add_custom_target, or
  file(GENERATE) commands.

The file libfolly.pc is generated from ./libfolly.pc.gen which is generated from ./CMake/libfolly.pc.in (a two-stage rocket). In libfolly.pc.in we see (among others):

Cflags: -I${includedir} @FOLLY_PKGCONFIG_CFLAGS@
Libs: -L${libdir} -lfolly
Libs.private: @FOLLY_PKGCONFIG_PRIVATE_LIBS@

where the Cflags line expands to

Cflags: -I${includedir} $<$<COMPILE_LANGUAGE:CUDA>:SHELL:-Xcompiler -pthread> $<$<NOT:$<COMPILE_LANGUAGE:CUDA>>:-pthread>  -std=gnu++1z -Werror=unknown-warning-option -DFMT_SHARED -DGFLAGS_IS_A_DLL=0 -I/usr/local/include -I/usr/include

(On FreeBSD at least) Notice that there's now generator expressions in there, which is what trips up CMake later when it passes the file through FILE(GENERATE). That might be what's tripping up CMake 3.18 (I'll know more once my current build finishes)

[adriaandegroot]

The CMake generator-expressions manpage suggests using file(GENERATE ... CONTENT ...) for debugging purposes, since that expands the generator at CMake-time. Which is what we need; something like this added to the top-level CMakeLists.txt does the trick:

# Expand the generator expressions that may have ended up in the CFLAGS,
# .. and then read them back so we write expanded expressions to the pkgconfig file.
set(_intermediate_filename "${CMAKE_CURRENT_BINARY_DIR}/gen.expansion")
file(GENERATE 
    OUTPUT ${_intermediate_filename}
    CONTENT "${FOLLY_PKGCONFIG_CFLAGS}")
file(READ ${_intermediate_filename FOLLY_PKGCONFIG_CFLAGS)

[adriaandegroot]

.. even without the missing } in the code sample above, it's still broken. I wonder if it even makes sense to end up with generator expressions in the PC -- those reflect the generator in use now, not the thing consuming the .pc file.

[emmenlau]

Dear @adriaandegroot , thanks a lot for these insights! But, may I ask quite naiive: why is there a libfolly.pc in the first place? I understand that this may be helpful for people using pkgconfig, but at least for me the error is with cmake. I could accept that the auto-generated pkgconfig configuration is currently broken. But it seems an unnecessary escalation of the problem that this in turn breaks the cmake configuration, i.e. since cmake has a quite powerful dependency tracking and options passing mechanism itself?

Cutting a long story short: could the cmake-based build stop reading (and failing on) libfolly.pc?

After re-reading the code, I see that you are right about the issue. cmake trips over the generation of libfolly.pc (or libfolly.pc.gen). So I guess your suggestion of expanding the generator expressions is the best way to proceed.

Also, this basically means that folly is currently not compatible with cmake 3.18+

[emmenlau]

Also, it seems #1232 should have solved this problem?

[adriaandegroot]

@emmenlau Yes, it's cmake tripping over the generation. The older issue #1232 builds a "two stage" generation for expansion, but it's new that this specific generator expression leaks into the build. I've filed an upstream CMake bug, https://gitlab.kitware.com/cmake/cmake/-/issues/21074 , as well.

The same problem affects https://github.com/arvidn/libtorrent/

[adriaandegroot]

--- CMakeLists.txt.orig 2020-08-09 10:25:45 UTC
+++ CMakeLists.txt
@@ -437,6 +437,12 @@ install(
 
 # Generate a pkg-config file so that downstream projects that don't use
 # CMake can depend on folly using pkg-config.
+
+# Avoid things in the CFLAGS -- which can come from INTERFACE_OPTIONS
+# of dependencies -- that don't work with file(GENERATE). CMake bug 21074
+string(REPLACE "<COMPILE_LANG_AND_ID:CUDA,NVIDIA>" "<COMPILE_LANGUAGE:CUDA>" _s "${FOLLY_PKGCONFIG_CFLAGS}")
+set(FOLLY_PKGCONFIG_CFLAGS "${_s}")
+
 configure_file(
   ${CMAKE_CURRENT_SOURCE_DIR}/CMake/libfolly.pc.in
   ${CMAKE_CURRENT_BINARY_DIR}/libfolly.pc.gen

Is what I added to packaging, it basically resets CFLAGS that are going to the pkgconfig file to use the INTERFACE_OPTIONS that would have come from CMake 3.17, before the changes in 3.18. See the CMake issue for details.

[tambry]

CMake contributor here who introduced a feature resulting in a fix by another person, which caused this issue. CMake hasn't and will not guarantee stability and presence or lack there of of generator expressions on imported targets from builtin find modules. CMake doesn't consider this a regression.

The workaround by @adriaandegroot is sensible. However, this seems like a valid usecase with no general solution possible in CMake.
As a result, I added the TARGET argument to file(GENERATE) in CMake 3.19. This will allow specifying a target thus enabling resolution of target-dependent generator expressions.
I recommend using the workaround for CMake 3.18 only and the new TARGET argument for newer versions. Feel free to ping me if you require help making use of this.

[tambry]

See arvidn/libtorrent#5069 for an example of a workaround+fix.

[emmenlau]

Thanks @tambry that sounds good! Can/does folly already support this new TARGET argument when used with cmake >= 3.19? Or do you know when/how this will go into folly?

[tambry]

@emmenlau I've opened #1433, which includes a workaround for CMake 3.18. The TARGET argument solution will be guarded behind a version check will only be useful after the official 3.19 release, as CMake development versions still report as 3.18.

[emmenlau]

Perfect @tambry , thanks a lot! So I'll wait for #1433 to be merged and then close this issue!