Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Provide pkg-config integration for system's packaging #198

Closed
dvzrv opened this issue Nov 3, 2022 · 10 comments
Closed

Provide pkg-config integration for system's packaging #198

dvzrv opened this issue Nov 3, 2022 · 10 comments
Assignees

Comments

@dvzrv
Copy link

dvzrv commented Nov 3, 2022

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).

@abique
Copy link
Contributor

abique commented Nov 3, 2022

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...?

@abique
Copy link
Contributor

abique commented Nov 3, 2022

Also, are you packaging:

For clap-host and clap-plugins I've already made AUR packages.

@dvzrv
Copy link
Author

dvzrv commented Nov 3, 2022

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 😉 ) 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?

@abique
Copy link
Contributor

abique commented Nov 3, 2022

Are the other projects something end users or developers would be able to use?

Yes they can be useful to developers.

@abique
Copy link
Contributor

abique commented Nov 3, 2022

Robbert fixed it.
It'll be included for 1.1.3.

@dvzrv
Copy link
Author

dvzrv commented Nov 3, 2022

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! 🎉

@dvzrv
Copy link
Author

dvzrv commented Nov 27, 2022

Is there an ETA for the 1.1.3 release?

@abique
Copy link
Contributor

abique commented Nov 28, 2022

I'll try to speed up that one, sorry for the delay.

@abique
Copy link
Contributor

abique commented Nov 28, 2022

@dvzrv I've started #217
Please can you verify that the changes for adding the pkgconfig file works well for you? (try the next branch)

@abique
Copy link
Contributor

abique commented Dec 22, 2022

@dvzrv 1.1.4 contains the pkg-config files.

@abique abique closed this as completed Dec 22, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants