Closed dvzrv closed 1 year ago
Hi David,
Here I'm not certain it is the right approach. I believe each plugin should be built against their own copy of clap, by having either a hard copy or a git submodule. That's what I did in clap-host and clap-plugins.
Yet I can understand that if you distribute a whole system, it can be interesting to have hard guarantees that everything was built using the same headers.
If we provide a clap.pc.in
, do we then also need to provide a FindCLAP.cmake
etc...?
Also, are you packaging:
For clap-host and clap-plugins I've already made AUR packages.
If we provide a clap.pc.in, do we then also need to provide a FindCLAP.cmake etc...?
You can. However, CMake is also able to make use of pkg-config via FindPkgConfig. For people on Windows CMake is likely the easier integration path though... then again, everything is different on Windows and I am no expert on how to do things there... In case you want CMake integration, it can be added, too. The pkg-config integration is definitely the common denominator, though, so a separate ticket/PR might make more sense?
Here I'm not certain it is the right approach. I believe each plugin should be built against their own copy of clap, by having either a hard copy or a git submodule. That's what I did in clap-host and clap-plugins.
Frankly, I don't think you will be able to dissuade people from wanting to integrate clap as a versioned dependency in their build systems :) Using hard copies is overhead (one needs to copy stuff around and keep track of that) and also using git submodules is inconvenient (they are not present in auto-generated tarballs, requiring extra scripting to create release tarballs, etc.) in comparison to bumping a version number in a text file.
Yet I can understand that if you distribute a whole system, it can be interesting to have hard guarantees that everything was built using the same headers.
The pkg-config files are pretty much the standard (unless you only want to support cmake :wink: ) IMHO and there is no harm in providing them. FWIW, bundling different versions of dependencies is a security problem and also a handling problem for downstreams. The more plugins directly build against clap in some version on free downstream platforms, the more important it will become to have system integration for clap, so that plugins may define e.g. which version of clap they require (i.e. by checking the system's pkg-config file for clap).
Also, are you packaging:
No, not at the moment at least. I only require clap for building. The clap-helpers repo does not have a release yet. Are the other projects something end users or developers would be able to use?
Are the other projects something end users or developers would be able to use?
Yes they can be useful to developers.
Robbert fixed it. It'll be included for 1.1.3.
Yes they can be useful to developers.
I'll look into those then as well. Probably not this week though
Robbert fixed it. It'll be included for 1.1.3.
yay! :tada:
Is there an ETA for the 1.1.3 release?
I'll try to speed up that one, sorry for the delay.
@dvzrv I've started https://github.com/free-audio/clap/pull/217 Please can you verify that the changes for adding the pkgconfig file works well for you? (try the next branch)
@dvzrv 1.1.4 contains the pkg-config files.
Hi! I'm packaging things for Arch Linux and inevitably clap will have to be packaged soon (yabridge requires it now).
It would be really cool, if there was a pkg-config file, so that build systems can make use of system-wide installations of clap.
In the current setup I can only e.g. package the files below
include
to/usr/include/
, but no build system (e.g. meson, cmake, autofools) would know about its existence and version without a pkg-config integration.It would be great to have a
clap.pc.in
file which gets configured by your cmake setup and then gets installed alongside the header files to the default integration location (e.g. something like/usr/lib/pkgconfig/clap.pc
on Arch Linux).