Build failure with cmake 3.19.2

I did this

Trying to configure 8.6.0 (or master) using cmake 3.19.2 results in the error:

-- Enabled SSL backends: OpenSSL
-- Configuring done
CMake Error:
  Error evaluating generator expression:

    $<LIST:TRANSFORM,curl_easy_cleanup.3;curl_easy_duphandle.3;curl_easy_escape.3;curl_easy_getinfo.3;curl_easy_header.3;curl_easy_init.3;curl_easy_nextheader.3;curl_easy_option_by_id.3;curl_easy_option_by_name.3;curl_easy_option_next.3;curl_easy_pause.3;curl_easy_perform.3;curl_easy_recv.3;curl_easy_reset.3;curl_easy_send.3;curl_easy_setopt.3;curl_easy_strerror.3;curl_easy_unescape.3;curl_easy_upkeep.3;curl_escape.3;curl_formadd.3;curl_formfree.3;curl_formget.3;curl_free.3;curl_getdate.3;curl_getenv.3;curl_global_cleanup.3;curl_global_init.3;curl_global_init_mem.3;curl_global_trace.3;curl_global_sslset.3;curl_mime_addpart.3;curl_mime_data.3;curl_mime_data_cb.3;curl_mime_encoder.3;curl_mime_filedata.3;curl_mime_filename.3;curl_mime_free.3;curl_mime_headers.3;curl_mime_init.3;curl_mime_name.3;curl_mime_subparts.3;curl_mime_type.3;curl_mprintf.3;curl_multi_add_handle.3;curl_multi_assign.3;curl_multi_cleanup.3;curl_multi_fdset.3;curl_multi_get_handles.3;curl_multi_info_read.3;curl_multi_init.3;curl_multi_perform.3;curl_multi_poll.3;curl_multi_remove_handle.3;curl_multi_setopt.3;curl_multi_socket.3;curl_multi_socket_action.3;curl_multi_socket_all.3;curl_multi_strerror.3;curl_multi_timeout.3;curl_multi_wakeup.3;curl_multi_wait.3;curl_pushheader_bynum.3;curl_pushheader_byname.3;curl_share_cleanup.3;curl_share_init.3;curl_share_setopt.3;curl_share_strerror.3;curl_slist_append.3;curl_slist_free_all.3;curl_strequal.3;curl_strnequal.3;curl_unescape.3;curl_url.3;curl_url_cleanup.3;curl_url_dup.3;curl_url_get.3;curl_url_set.3;curl_url_strerror.3;curl_version.3;curl_version_info.3;curl_ws_meta.3;curl_ws_recv.3;curl_ws_send.3;libcurl-easy.3;libcurl-env.3;libcurl-env-dbg.3;libcurl-errors.3;libcurl-multi.3;libcurl-security.3;libcurl-share.3;libcurl-symbols.3;libcurl-thread.3;libcurl-tutorial.3;libcurl-url.3;libcurl-ws.3;libcurl.3,PREPEND,/home/dan/src/curl-git/build/docs/libcurl/>

  Expression did not evaluate to a known generator expression

~~Bisecting shows commit a808aab is at fault~~. This version of cmake is only a couple of years old and the documentation says cmake 3.7 is the earliest supported version, so I would expect this to work.

I expected the following

cmake should run without error.

curl/libcurl version

curl 8.6.0

operating system

Linux x86_64

@dfandrich

@dfandrich: This syntax was in fact introduced a few commits earlier in ea0b575 (not by me).

It's a new here that someone must be pointed out by name to be "at fault"!

Commit 1621136 (the previous one) configures fine but commit a808aab is the one that starts showing this problem (at least without specifying any build options on my system).

These still have nothing to do with the introduction of the breaking CMake syntax.

It's trivial to look up when it was introduced:

$ git log -S 'LIST:TRANSFORM'
commit ea0b575dab86a3c44dd1d547dc500276266aa382
[...]

The reason you are not seeing the problem earlier, is because my "at fault" (your wording) commit made the libcurl manual option to work by default (that is without having to manually enable building the curl manual too with another option). But, given the necessary options, you'd see the same issue after the initial commit.

@levitte

Makes, sense and what I was hedging about with "without specifying any build options". @levitte, is there an alternate way of doing this that works on older cmake?

Can we do something in the builds/CI to detect when we rely on too new cmake features?

It was quite easy to replace the generator expression with a loop. Isn't quite as nice, but should be workable much further back in CMake versions.

This has me wonder if I should have a container in place with an old CMake, just to test this sort of thing (no, not just for curl...)

Anyway, fix in #12922

Can we do something in the builds/CI to detect when we rely on too new cmake features?

It's probably possible to install a cmake package with an appropriately old version.

Question is, how far back do the package repositories go? That being said, this can also be solved, by having a package repository of your own with suitably old stuff and try to install from that [yeah, cringe, and unsure if that's actually possible], or self-host a runner (for those CIs that permit it), again with suitably old stuff [yeah, cringe].

These are the versions in currently-supported LTS distros: 3.28.1: OpenSUSE Leap 15.6 3.20.2: CentOS 8 3.18.4: Debian 10/buster (a.k.a. oldstable) 3.17.0: SUSE SLE-12-SP5 3.16.3: Ubuntu 20.04LTS 3.10.2: Ubuntu 18.04ELTS 3.7.2: Debian 9/stretch (ELTS, so very limited support) 3.5.1: Ubuntu 16.04ELTS 3.0.2: Debian 8/jessie (ELTS, so very limited support) 2.8.12: CentOS 7 It looks like Debian stretch has the closest to what we want, namely exactly the oldest version we support. Debian ELTS gives very limited support, but for our purposes of building something and not running it on the live Internet in a production capacity, it should be sufficient: https://wiki.debian.org/LTS/Extended I just tried setting up a Debian 9 container with ELTS packages (with cmake 3.7.2) and it worked fine with docs disabled. With docs enabled and PR#12922 applied, it failed because of another LIST:TRANSFORM elsewhere. But this looks like a viable approach.

Ports: Update curl to 8.6.0

cmake: fix install for older CMake versions

Ports: Patch curl CMake issue

I worked around this using the BUILD_LIBCURL_DOCS=OFF CMake option

Navigation Menu

Repository navigation

Build failure with cmake 3.19.2 #12920

I did this

I expected the following

curl/libcurl version

operating system

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Build failure with cmake 3.19.2 #12920

Description

I did this

I expected the following

curl/libcurl version

operating system

Activity

vszakats commented on Feb 9, 2024

dfandrich commented on Feb 10, 2024

vszakats commented on Feb 10, 2024

vszakats commented on Feb 10, 2024

dfandrich commented on Feb 10, 2024

bagder commented on Feb 10, 2024

levitte commented on Feb 10, 2024

levitte commented on Feb 10, 2024

dfandrich commented on Feb 10, 2024

thomgree commented on Feb 28, 2024

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions