#1762 Compile error

[Philip Leishman]

So just getting back to looking at things and I find I cannot compile the newest git version.
The problem is finding the jack library,
Note I use pipewire and I do not have the jack development libraries installed - relying on the pipewire version. This used to work OK but is now broken. - something to do with that find_library call in cmake ??
This seems to have come in commit [32dcaf]

[Philip Leishman]

I reverted the find_library cmake call and it works again.
Maybe we can do better ?
See merge request.

[Ted Felix]

So that's what that was for. I dug deep into the mailing lists, git blame, and the bug tracker and found nothing that was a clear explanation. It'd be nice if there had been comments explaining. Ok, I'll revert the mess I made with [32dcaf] and add some comments. Thanks for catching. I'll have a look tonight.

[Ted Felix]

Ok, I merged in your revert and rewrote the comment block. Please test latest git [40dc64].

It would be nice if the cmake code were clearer, but I'm not sure the real world allows for that.

[Philip Leishman]

Works for me.
The internet recommends something like:
target_link_libraries(<target> ${XXX_LINK_LIBRARIES})
Maybe that would be clearer ?

[Ted Felix]

Based on digging through the mailing list archives, I believe target_link_libraries() is what started the issue. It is not available in the version of cmake that we support (3.10). I think it is introduced in 3.13 or 3.15. That led to the code that is there now which works for 3.10.

I would rather see a meta package discovery function that first tries to find a .cmake file, then a .pc file (pkg_check_modules()), then falls back on find_library(). Or perhaps just use find_library() for everything since it always seems to just work. I think that's the way cmake has been heading since .cmake and .pc files are not guaranteed. And target_link_libraries() is probably required to do this right.

Not sure cmake is worth spending time on. It's back to working now.

[David Faure]

I might be able to help, but I'm a bit confused about what's the problem ;)
One thing though: I see a comment in a commit that says "we should do something more direct, like checking for a pipewire .cmake or .pc file. But maybe there is no such thing? "
The answer is clear, there's no cmake file provided by pipewire, but there's a pkgconfig file, e.g.
/usr/lib64/pkgconfig/libpipewire-0.3.pc on my system (OpenSUSE).
It says libdir=/usr/lib64 and moduledir=/usr/lib64/pipewire-0.3, and indeed there's a /usr/lib64/pipewire-0.3/jack/libjack.so

HOWEVER, I see that /usr/lib64/pkgconfig/jack.pc already points to /usr/lib64/pipewire-0.3/jack so the current code finds it just fine. But that means this is one of the systems where pkg_check_modules(JACK jack) works just fine. I guess the issues that resulted from https://sourceforge.net/p/rosegarden/git/ci/32dcaf140e15960006e2234128871f7bef946476/ are systems where there is no such ready-to-use jack.pc pointing to pipewire?