cmake: set_target_properties on alias target

[malytomas]

I did this

Followup to #20313

running cmake with custom provided zlib fails:

CMake Error at externals/curl/curl/CMakeLists.txt:1820 (get_target_property):
  The LOCATION property may not be read from target "zlib-ng".  Use the
  target name directly with add_custom_command, or use the generator
  expression $<TARGET_FILE>, as appropriate.

CMake Error at externals/curl/curl/CMakeLists.txt:1821 (set_target_properties):
  set_target_properties can not be used on an ALIAS target.

in code:

curl/CMakeLists.txt

Line 1826 in c585282

get_target_property(_libname "${_lib}" LOCATION)

I expected the following

No response

curl/libcurl version

commit: 6437bd7

operating system

ubuntu 24, gcc, cmake 3.31

[vszakats]

After taking a second look at the previous report (#20313) I concluded
it's not a zlib-ng issue (or a zlib one), but an issue specific to this custom
cmake code, where ZLIB::ZLIB is defined as something incompatible
with what this system target normally is:

https://github.com/ucpu/cage/blob/2a45bbb374c76dd481a3a454eebbfc57ce4309ea/externals/zlib-ng/CMakeLists.txt#L30

(at first "zlib-ng" in the URL lead me believe this is a vendored
zlib-ng CMakeLists.txt, but it isn't.)

I don't have an idea how to work this around in curl cleanly and how
to keep it in mind in the future (let alone test for it). Even if detected,
what to assume and how to make the code work?

This is the canonical ZLIB::ZLIB definition by CMake:
https://github.com/Kitware/CMake/blob/f841f74290cc9dd4185efdc3e8b636861034004e/Modules/FindZLIB.cmake#L254-L275

Have you considered making ZLIB::ZLIB a native target, not an alias,
so that 3rd-party code works seamlessly with it?

[malytomas]

(at first "zlib-ng" in the URL lead me believe this is a vendored zlib-ng CMakeLists.txt, but it isn't.)

I apologize for causing confusion.

Curl is first project that I have encountered that is trying to modify the targets provided to it as dependency.

I would swear that namespace-scoped targets used to be aliases in find modules. I have seen it so many times and I myself have had so many issues with it, just like the one I just reported to you. I wonder if and when has that changed.

I myself avoid using find modules wherever possible as I build all third-party code from source - which is why I have custom targets in the first place, and also to be able to modify them as needed.

Anyway, thank you so much for looking into this. I will find a workaround.

[vszakats]

@malytomas No worries at all. I think the previous fix is fine,
because modifying a system target has a mild risk (even by adding
a namespaced property). In this case however, curl would only read
from it, which seem benign. I wonder why CMake doesn't allow it on
aliases. (FWIW the code is by itself a workaround for
a CMake + binutils ld issue, and should ideally not be necessary IMO.)

Classic zlib does define ZLIB::ZLIB in master since its CMake
overhaul in commit f7ab6e43732bc68b38ef5db5feda27105d954b5b
(2024-12). It's in the core build, and may hit this when used in
a "superbuild" together with a project that tries to read its props.
Hopefully it'll be fixed before released.

edit: actually curl's CMakeLists.txt looks like doing the same with
CURL::*. It may have been added with superbuilds in mind, but
I'm not sure, and did not dig into further.

[malytomas]

In this case however, curl would only read from it, which seem benign.

It reads, and next line also modifies a property too.

Anyway, in case of curiosity, I have tried some workarounds:

• the name of the target is given - it must be ZLIB::ZLIB - aka it must be namespaced name, which is restricted to imported or alias targets only.
• alias target cannot be modified.
• imported target must have IMPORTED_LOCATION, which must be a path to a real file, not a target, and cannot use generator expression. I do not know the actual path to the file, as it is built as part of my project.

So, I cannot possibly make a target that would have worked.

My final solution is that my cmake actually modifies your cmake, removing the whole section with the hack. And uses git update-index --assume-unchanged to suppress it. It works for me. This is third third-party project where I have resolved to modifying third-party code.

Again, thanks for such good reactions.

[vszakats]

In this case however, curl would only read from it, which seem benign.

It reads, and next line also modifies a property too.

Anyway, in case of curiosity, I have tried some workarounds:

• the name of the target is given - it must be ZLIB::ZLIB - aka it must be namespaced name, which is restricted to imported or alias targets only.
• alias target cannot be modified.
• imported target must have IMPORTED_LOCATION, which must be a path to a real file, not a target, and cannot use generator expression. I do not know the actual path to the file, as it is built as part of my project.

So, I cannot possibly make a target that would have worked.

My final solution is that my cmake actually modifies your cmake, removing the whole section with the hack. And uses git update-index --assume-unchanged to suppress it. It works for me. This is third third-party project where I have resolved to modifying third-party code.

Could it just find_package(ZLIB) and let CMake make
the target? Though if this is a "superbuild" all things get weird.
Modifying curl's CMake doesn't look very ideal though.

Again, thanks for such good reactions.

Oh, you're right. It's a bug I discovered a few days ago by
accident: #20382 (comment)
The code is supposed to be modifying a target in the CURL::
namespace. I did not manage to reproduce the original issue
to restest with the changes, and remained a local branch.
Opened a PR just in case → #20427

[malytomas]

Could it just find_package(ZLIB) and let CMake make the target?

There actually are multiple find_package(ZLIB) in my project (at least 4 libraries use it).
But I need to make sure that it finds my own.

I do binary distribution, even on linux, targeting very varied systems that are out of my control.
One reason to do "superbuilds" is to avoid most system dependencies. This shifts the burden of compatibility issues to the build phase, rather than runtime.
There are several more pros for superbuilds: full control over compile flags, optimizations, sse/avx, debugging, sanitizers, removing unneeded parts, ... It is shame that superbuilds arent very popular.

Modifying curl's CMake doesn't look very ideal though.

Indeed!
But my next best option is to completely bypass curl's cmake and write my own. I do that with several libraries too.

[vszakats]

Could it just find_package(ZLIB) and let CMake make the target?

There actually are multiple find_package(ZLIB) in my project (at least 4 libraries use it). But I need to make sure that it finds my own.

I do binary distribution, even on linux, targeting very varied systems that are out of my control. One reason to do "superbuilds" is to avoid most system dependencies. This shifts the burden of compatibility issues to the build phase, rather than runtime. There are several more pros for superbuilds: full control over compile flags, optimizations, sse/avx, debugging, sanitizers, removing unneeded parts, ... It is shame that superbuilds arent very popular.

They are useful, yes, basically serving as a portable scripting
language to make multi-project builds portable. They are also
the source of unexpected issues. It feels like CMake was not
designed for it from the ground up (my impression).

Indeed! But my next best option is to completely bypass curl's cmake and write my own. I do that with several libraries too.

Also doesn't seem very convenient.

This particular case is super annoying because we hit this
corner case because of other corner cases in cmake and
binutils' ld tool with static builds. The latter is a many-decade
old problem, the other is something that cmake actively does
when using interface targets: breaking lib order, which then
breaks binutils. Cause of much grey hair and time-waste.

In any case, if someone has a better suggestion how to
clone/copy a system interface target into a custom one
without reading its property. Or, aware of a way to retain, or
influence lib order when using interface targets, or any other
solution, I'm happy to learn them.

[ Today's surprise it that the above is fixed by setting
INTERFACE_LINK_LIBRARIES on ZLIB::ZLIB. I don't know
why this works, and curl definitely should not write into that target. ]

[vszakats]

@malytomas:

I tried to reproduce this with a minimal CMakeLists.txt:

cmake_minimum_required(VERSION 3.10)
project(TEST C)

find_package(ZLIB)

add_library(foo::bar ALIAS ZLIB::ZLIB)

if(TARGET ZLIB::ZLIB)
  get_target_property(_libname ZLIB::ZLIB LOCATION)
  get_target_property(_aliased ZLIB::ZLIB ALIASED_TARGET)
  message(STATUS "original |${_libname}|${_aliased}|")
endif()
if(TARGET foo::bar)
  get_target_property(_libname foo::bar LOCATION)
  get_target_property(_aliased foo::bar ALIASED_TARGET)
  message(STATUS "alias |${_libname}|${_aliased}|")
endif()

but, it's running fine, able to read LOCATION from the
alias, just like from the original:

$ cmake .
-- original |.../usr/lib/libz.tbd|_aliased-NOTFOUND|
-- alias |.../usr/lib/libz.tbd|ZLIB::ZLIB|
-- Configuring done (0.1s)
-- Generating done (0.0s)

This suggests aliasing isn't the issue? Maybe the LOCATION
property is missing?

Meanwhile #20427 landed, and if it's only the set property
that's causing the issue as in title, it may be fixed.

[malytomas]

In my case the alias is created in cmakelist in different directory, that sometimes also plays a role.

I will test curl master with the latest changes later this week.

[malytomas]

I have tried the latest version and it works, but I still do need my workaround.

This suggests aliasing isn't the issue? Maybe the LOCATION property is missing?

Indeed in my case the location property is missing, as it is normal target, with build rules, not imported.
I have not tried to set location on it, I do not know what that would do. It might potentially work now, that the only issue is the read operation, without modifications.