Produce a specification for .pc files #148

New Issue

ariadne · 2017-10-13T16:59:15Z

pwithnall commented

2017-10-13 16:59:15 +00:00

(Migrated from github.com)

If pkgconf and pkg-config are both going to be potentially used by different people (for example, on different distros) to compile the same source code (another FOSS project), they’re both going to be consuming the same .pc files.

Currently there isn’t a comprehensive specification of the syntax or semantics of a .pc file. In order to avoid incompatibilities between the two implementations, there probably should be. Ideally it would be reviewed by both the pkgconf and pkg-config authors, and include some thoughts about forwards compatibility so that pkgconf could have scope to improve/extend the .pc format in future without breaking users who are using pkg-config.

Someone has written a specification up, which would be a good starting point (assuming they are OK with derivations of it — it’s CC-BY 3.0): https://dev.gentoo.org/~mgorny/pkg-config-spec.html

If `pkgconf` and `pkg-config` are both going to be potentially used by different people (for example, on different distros) to compile the same source code (another FOSS project), they’re both going to be consuming the same `.pc` files. Currently there isn’t a comprehensive specification of the syntax or semantics of a `.pc` file. In order to avoid incompatibilities between the two implementations, there probably should be. Ideally it would be reviewed by both the `pkgconf` and `pkg-config` authors, and include some thoughts about forwards compatibility so that `pkgconf` could have scope to improve/extend the `.pc` format in future without breaking users who are using `pkg-config`. Someone has written a specification up, which would be a good starting point (assuming they are OK with derivations of it — it’s CC-BY 3.0): https://dev.gentoo.org/~mgorny/pkg-config-spec.html

ariadne commented

2017-10-14 02:55:23 +00:00

We have thought about formally specifying the .pc format a few times. mgorny was involved in pkgconf at an early stage, and that's where that spec came from.

We had some talks with the pkg-config maintainer about it a while back, but it didn't really develop into anything.

We do not need to have a specification in order to improve the .pc format as we intend to do.

A package which requires pkgconf extensions today can simply declare it's dependency on the pkgconf virtual like:

Name: foo
Version: 1
Requires: pkgconf > [version the extension was introduced in]

It may be interesting to add an extension: namespace for specific extensions, for example:

Name: foo
Version: 1
Requires: extension:cflags-private
CFlags.private: -DLINK_STATIC

In our view, this is the most realistic way forward... a specification that codifies legacy pkg-config behaviour is entirely antithetical to what we are trying to accomplish with this project.

We have thought about formally specifying the .pc format a few times. mgorny was involved in pkgconf at an early stage, and that's where that spec came from. We had some talks with [the pkg-config maintainer about it a while back](https://lists.freedesktop.org/archives/pkg-config/2012-September/thread.html), but it didn't really develop into anything. We do not need to have a specification in order to improve the .pc format as we intend to do. A package which requires pkgconf extensions today can simply declare it's dependency on the pkgconf virtual like: ``` Name: foo Version: 1 Requires: pkgconf > [version the extension was introduced in] ``` It may be interesting to add an `extension:` namespace for specific extensions, for example: ``` Name: foo Version: 1 Requires: extension:cflags-private CFlags.private: -DLINK_STATIC ``` In our view, this is the most realistic way forward... a specification that codifies legacy pkg-config behaviour is entirely antithetical to what we are trying to accomplish with this project.

ariadne commented

2017-10-14 03:24:51 +00:00

To expand on this, I believe a specification is basically impossible.

pkgconf and pkg-config implement many things in entirely different ways, such as cross-compiling support.

For example:

With pkgconf, it is possible to have a single binary and define many sysroots and have everything just work with a wrapper script.

With pkg-config, it is possible to have a single binary and define many sysroots and making everything work requires adding cross-compilation details to the .pc files as well as a wrapper script. As a result cross-toolchains build their own copy of pkg-config that is configured relative to the sysroot.

Both interpretations could be considered valid, which should the spec choose?

There are other corner cases between the implementations that are intentional (because pkgconf comes from years of frustration with using pkg-config for embedded development) and a specification requiring the freedesktop.org pkg-config behaviour be correct is basically a specification we would be extremely unlikely to implement (because we do not want to break our own tools in the same way that pkg-config is broken for embedded development).

To expand on this, I believe a specification is basically impossible. pkgconf and pkg-config implement many things in entirely different ways, such as cross-compiling support. For example: With pkgconf, it is possible to have a single binary and define many sysroots and have everything just work with a wrapper script. With pkg-config, it is possible to have a single binary and define many sysroots and making everything work requires adding cross-compilation details to the .pc files as well as a wrapper script. As a result cross-toolchains build their own copy of pkg-config that is configured relative to the sysroot. Both interpretations could be considered valid, which should the spec choose? There are other corner cases between the implementations that are intentional (because pkgconf comes from years of frustration with using pkg-config for embedded development) and a specification requiring the freedesktop.org pkg-config behaviour be correct is basically a specification we would be extremely unlikely to implement (because we do not want to break our own tools in the same way that pkg-config is broken for embedded development).

ariadne commented

2017-10-14 07:54:45 +00:00

With all of that said I am keeping this open because there is value in specifying what pkgconf accepts.

The problem really comes down to using a spec to improve interoperability: it just seems so unlikely to me that I don’t want to spend time on it. If anything, the best outcome would be that pkg-config corrects some of the design defects in its implementation but like I said seems unlikely.

I would be open to specifying a subset of what pkgconf accepts as part of a POSIX or similar standard however.

With all of that said I am keeping this open because there is value in specifying what pkgconf accepts. The problem really comes down to using a spec to improve interoperability: it just seems so unlikely to me that I don’t want to spend time on it. If anything, the best outcome would be that pkg-config corrects some of the design defects in its implementation but like I said seems unlikely. I would be open to specifying a subset of what pkgconf accepts as part of a POSIX or similar standard however.

pwithnall commented

2017-10-16 10:22:23 +00:00

(Migrated from github.com)

Basically, the problem I want to avoid is: people writing .pc files which behave differently under pkgconf and pkg-config, without knowing that they should also make those .pc files explicitly depend on pkgconf (or pkg-config). I want to avoid the situation where my project builds (or can be built against, if it’s a library exporting a .pc file) absolutely fine on one system; but then fails or builds incorrectly on another system which is using pkg-config instead of pkgconf (or vice-versa). This could be avoided by having a specification of what pkgconf accepts, as long as that also points out where pkgconf’s behaviour differs from pkg-config.

Secondarily, I want to avoid people cargo-culting .pc files from other projects and not really understanding what the keys in the .pc file mean. That can also be solved by a specification of what pkgconf accepts.

Basically, the problem I want to avoid is: people writing `.pc` files which behave differently under `pkgconf` and `pkg-config`, without knowing that they should also make those `.pc` files explicitly depend on `pkgconf` (or `pkg-config`). I want to avoid the situation where my project builds (or can be built against, if it’s a library exporting a `.pc` file) absolutely fine on one system; but then fails or builds incorrectly on another system which is using `pkg-config` instead of `pkgconf` (or vice-versa). This could be avoided by having a specification of what `pkgconf` accepts, as long as that also points out where `pkgconf`’s behaviour differs from `pkg-config`. Secondarily, I want to avoid people cargo-culting `.pc` files from other projects and not really understanding what the keys in the `.pc` file mean. That can also be solved by a specification of what `pkgconf` accepts.

ariadne commented

2017-10-16 16:23:55 +00:00

Yeah, that's a huge problem, especially the cargo-culting.

I agree some solid documentation of the format is good, and I think the gating approach I described earlier can solve the pkg-config vs. pkgconf concern.

I will see what I can do :)

Yeah, that's a huge problem, especially the cargo-culting. I agree some solid documentation of the format is good, and I think the gating approach I described earlier can solve the pkg-config vs. pkgconf concern. I will see what I can do :)

pwithnall commented

2017-10-16 16:43:43 +00:00

(Migrated from github.com)

Great, thanks. I’m happy to proofread things if that will help.

Conan-Kudo commented

2017-10-16 19:26:32 +00:00

(Migrated from github.com)

@kaniini For what it's worth, it has been requested that at least a man page that documents what a pc file looks like and what the directives do be included in pkgconf.

See downstream RH bug: https://bugzilla.redhat.com/show_bug.cgi?id=1416434

@kaniini For what it's worth, it has been requested that at least a man page that documents what a pc file looks like and what the directives do be included in pkgconf. See downstream RH bug: https://bugzilla.redhat.com/show_bug.cgi?id=1416434

ariadne commented

2017-10-17 17:09:10 +00:00

I think that a manpage describing the format should be a separate manpage. Thoughts?

Conan-Kudo commented

2017-10-17 17:43:21 +00:00

(Migrated from github.com)

@kaniini Absolutely, I agree.