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

[Liliana Marie Prikler]

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