[bug#56286,3/3] gnu: Add pkgconf.

  Note that this package produces a `guix lint` warning that is basically
unfixable:

```
/home/paren/code/guix/gnu/packages/pkg-config.scm:213:16:
pkgconf@1.8.0-0.b0802cb: TLS certificate error: X.509 server certificate
for 'pkgconf.org' does not match:
C=US,ST=California,L=San Francisco,O=GitHub\, Inc.,CN=*.github.com
```

This is because pkgconf.org is actually hosted via Github Pages.

* gnu/packages/pkg-config.scm (pkgconf): New variable.
---
 gnu/packages/pkg-config.scm | 48 +++++++++++++++++++++++++++++++++++++
 1 file changed, 48 insertions(+)
  

Am Dienstag, dem 28.06.2022 um 19:08 +0100 schrieb (:
> Note that this package produces a `guix lint` warning that is
> basically unfixable:
> 
> ```
> /home/paren/code/guix/gnu/packages/pkg-config.scm:213:16:
> pkgconf@1.8.0-0.b0802cb: TLS certificate error: X.509 server
> certificate
> for 'pkgconf.org' does not match:
> C=US,ST=California,L=San Francisco,O=GitHub\, Inc.,CN=*.github.com
> ```
> 
> This is because pkgconf.org is actually hosted via Github Pages.
Note that plain HTTP works :)

> * gnu/packages/pkg-config.scm (pkgconf): New variable.
> ---
>  gnu/packages/pkg-config.scm | 48
> +++++++++++++++++++++++++++++++++++++
>  1 file changed, 48 insertions(+)
> 
> diff --git a/gnu/packages/pkg-config.scm b/gnu/packages/pkg-
> config.scm
> index dcd6ba3353..8c826ca25d 100644
> --- a/gnu/packages/pkg-config.scm
> +++ b/gnu/packages/pkg-config.scm
> @@ -24,9 +24,11 @@ (define-module (gnu packages pkg-config)
>    #:use-module (guix build-system gnu)
>    #:use-module (guix download)
>    #:use-module (guix gexp)
> +  #:use-module (guix git-download)
>    #:use-module ((guix licenses) #:prefix license:)
>    #:use-module (guix memoization)
>    #:use-module (guix packages)
> +  #:use-module (gnu packages autotools)
>    #:use-module (gnu packages bash)
>    #:export (pkg-config))
>  
> @@ -168,3 +170,49 @@ (define where (string-append #$output "/bin/pkg-
> config"))
>               (inherit original)
>               (variable "PKG_CONFIG_PATH_FOR_BUILD")))
>            (package-native-search-paths %pkg-config)))))
> +
> +(define-public pkgconf
> +  ;; The last release was tagged on 2021-07-25, and there's been a
> lot of activity
> +  ;; since then.
> +  (let ((commit "b0802cb3d19b5b963ad20eed464a2da6e7d7b0b5")
> +        (revision "0"))
> +    (package
> +     (name "pkgconf")
> +     (version (git-version "1.8.0" revision commit))
> +     (source (origin
> +              (method git-fetch)
> +              (uri (git-reference
> +                    (url "https://github.com/pkgconf/pkgconf")
> +                    (commit commit)))
> +              (file-name (git-file-name name version))
> +              (sha256
> +               (base32
> +               
> "1xcpvzahrp34jhdfsazdhbj9byr2wqwmjx7jfarhpc1x4z3l37a0"))))
> +     (build-system gnu-build-system)
> +     (arguments
> +      ;; Kyua, which pkgconf uses for testing, is not packaged in
> Guix,
> +      ;; though it should be trivial to add; the problem is that it
> "cannot
> +      ;; find test programs" that it needs when run during this
> package's
> +      ;; check phase.
> +      ;;
Did you try running check after install?  That is often required by
package which don't do pre-inst-env well.
> +      ;; The silver lining is that omitting Kyua means we drop
> dependencies
> +      ;; on pkg-config, Lua, and C++. It does not, in fact, seem as
> if the
> +      ;; tests are even supposed to be run by anyone but the pkgconf
> +      ;; developers, as <https://pkgconf.org> touts pkgconf's
> dependency-free
> +      ;; nature as an advantage over pkg-config.
I think this is a misinterpretation on your part or a confusing wording
on theirs.  Basically, pkgconf does not *link* against any "huge"
binary, so it's fine.  Never mind that glib is a sane dependency to
have or that it also complains about pkg-config's license, which is
most meaningless in the context of tools you invoke at build time.
> +      (list #:tests? #f))
> +     (native-inputs (list ;; pkgconf's autotools setup forbids the
> use of any
> +                          ;; earlier version of autoconf than 2.71.
> +                          autoconf-2.71
> +                          automake
> +                          libtool))
> +     (native-search-paths
> +      (list (search-path-specification
> +             (variable "PKG_CONFIG_PATH")
> +             (files '("lib/pkgconfig" "lib64/pkgconfig"
> "share/pkgconfig")))))
I'm not sure if we want to provide $PKG_CONFIG_PATH as a variable, but
there's at least two definitions within the same file now :)
> +     (home-page "https://pkgconf.org")
> +     (synopsis "Package compiler and linker metadata toolkit")
> +     (description "@code{pkgconf} is a compiler and linker
> configuration toolkit,
> +mostly compatible with freedesktop.org's @code{pkg-config}.  A
> library called
> +@code{libpkgconf} is provided so that programs can embed its
> functionality.")
> +     (license license:isc))))

Cheers
  

On Tue Jun 28, 2022 at 8:13 PM BST, Liliana Marie Prikler wrote:
> I think this is a misinterpretation on your part or a confusing wording
> on theirs.  Basically, pkgconf does not *link* against any "huge"
> binary, so it's fine.  Never mind that glib is a sane dependency to
> have or that it also complains about pkg-config's license, which is
> most meaningless in the context of tools you invoke at build time.

You make an excellent point there. I'll add the guixrus kyua package and
its dependencies in a moment. Hopefully your note about using check
after install will work. Is there an easy way to switch them around?

> > +      (list #:tests? #f))
> > +     (native-inputs (list ;; pkgconf's autotools setup forbids the
> > use of any
> > +                          ;; earlier version of autoconf than 2.71.
> > +                          autoconf-2.71
> > +                          automake
> > +                          libtool))
> > +     (native-search-paths
> > +      (list (search-path-specification
> > +             (variable "PKG_CONFIG_PATH")
> > +             (files '("lib/pkgconfig" "lib64/pkgconfig"
> > "share/pkgconfig")))))
> I'm not sure if we want to provide $PKG_CONFIG_PATH as a variable, but
> there's at least two definitions within the same file now :)
What alternative would there be to providing $PKG_CONFIG_PATH as a
variable?

    -- (
  

Am Dienstag, dem 28.06.2022 um 20:20 +0100 schrieb (:
> On Tue Jun 28, 2022 at 8:13 PM BST, Liliana Marie Prikler wrote:
> > I think this is a misinterpretation on your part or a confusing
> > wording
> > on theirs.  Basically, pkgconf does not *link* against any "huge"
> > binary, so it's fine.  Never mind that glib is a sane dependency to
> > have or that it also complains about pkg-config's license, which is
> > most meaningless in the context of tools you invoke at build time.
> 
> You make an excellent point there. I'll add the guixrus kyua package
> and its dependencies in a moment. Hopefully your note about using
> check after install will work. Is there an easy way to switch them
> around?
The standard way would be
  (delete 'check)
  (add-after 'install 'check (assoc-ref %standard-phases 'check))

> > > +      (list #:tests? #f))
> > > +     (native-inputs (list ;; pkgconf's autotools setup forbids
> > > the
> > > use of any
> > > +                          ;; earlier version of autoconf than
> > > 2.71.
> > > +                          autoconf-2.71
> > > +                          automake
> > > +                          libtool))
> > > +     (native-search-paths
> > > +      (list (search-path-specification
> > > +             (variable "PKG_CONFIG_PATH")
> > > +             (files '("lib/pkgconfig" "lib64/pkgconfig"
> > > "share/pkgconfig")))))
> > I'm not sure if we want to provide $PKG_CONFIG_PATH as a variable,
> > but
> > there's at least two definitions within the same file now :)
> What alternative would there be to providing $PKG_CONFIG_PATH as a
> variable?
I mean as a Scheme variable, rather than typing it out twice.  It's not
the biggest priority right now, but if another pkg-config
implementation rolls around, we might want to consider $PKG_CONFIG_PATH
a "standard" search-path.

Cheers
  

Am Dienstag, dem 28.06.2022 um 21:45 +0200 schrieb Liliana Marie
Prikler:
> I mean as a Scheme variable, rather than typing it out twice.  It's
> not the biggest priority right now, but if another pkg-config
> implementation rolls around, we might want to consider
> $PKG_CONFIG_PATH a "standard" search-path.
Following up to that, I think I am slightly annoyed by typing out the
same thing twice.  You could use (package-native-search-paths pkg-
config) instead, especially since they're in the same module and all.

Cheers
  

On Tue Jun 28, 2022 at 8:46 PM BST, Liliana Marie Prikler wrote:
> Following up to that, I think I am slightly annoyed by typing out the
> same thing twice.  You could use (package-native-search-paths pkg-
> config) instead, especially since they're in the same module and all.

Ah, nice idea! Thanks :)

    -- (