~skeeto/public-inbox

2 2

Re: u-config: a new, lean pkg-config clone

Andrius Štikonas <andrius@stikonas.eu>
Details
Message ID
<1750680.o7JgDH7DvH@laptop>
DKIM signature
missing
Download raw message
pkg-config does not require pkg-config to build itself as proven by live-bootstrap:
https://github.com/fosslinux/live-bootstrap/blob/master/parts.rst
and is perfectly bootstrappable.

Re: u-config: a new, lean pkg-config clone

Details
Message ID
<20230118235405.26cgw277zupzrmxe@nullprogram.com>
In-Reply-To
<1750680.o7JgDH7DvH@laptop> (view parent)
DKIM signature
missing
Download raw message
My main complaint is that bootstrapping is necessary in the first place, 
because it's ridiculous and, as demonstrated, easily avoided. It's the top 
listed reason why FreeBSD switched to pkgconf:

https://www.mail-archive.com/freebsd-ports-announce@freebsd.org/msg00018.html

I myself had observed the pkg-config configure script invoking pkg-config 
(configurable via PKG_CONFIG). However, I hadn't realized until just now 
that --with-internal-glib prevents the build from using pkg-config, which 
breaks the loop. So if got the autotools outputs working on busybox-w32, 
the bootstrap wouldn't have been an impediment because I'd be using the 
embedded glib which it can find and use without pkg-config. I've added a 
note about this to the article, so thanks for pointing it out.

Distributions must still bootstrap pkg-config in a two-stage process if 
they want to link against the system glib, which they typically do.

Re: u-config: a new, lean pkg-config clone

Details
Message ID
<cb298af2-ad30-9642-81ae-702ed5e42cdc@gmail.com>
In-Reply-To
<20230118235405.26cgw277zupzrmxe@nullprogram.com> (view parent)
DKIM signature
missing
Download raw message
On 1/18/23 6:54 PM, Christopher Wellons wrote:
> My main complaint is that bootstrapping is necessary in the first place,
> because it's ridiculous and, as demonstrated, easily avoided. It's the
> top listed reason why FreeBSD switched to pkgconf:
> 
> https://www.mail-archive.com/freebsd-ports-announce@freebsd.org/msg00018.html


Yeah, the use of glib is... basically trivial and makes very little
sense there.


> I myself had observed the pkg-config configure script invoking
> pkg-config (configurable via PKG_CONFIG). However, I hadn't realized
> until just now that --with-internal-glib prevents the build from using
> pkg-config, which breaks the loop. So if got the autotools outputs
> working on busybox-w32, the bootstrap wouldn't have been an impediment
> because I'd be using the embedded glib which it can find and use without
> pkg-config. I've added a note about this to the article, so thanks for
> pointing it out.
> 
> Distributions must still bootstrap pkg-config in a two-stage process if
> they want to link against the system glib, which they typically do.


This is actually considerably more fun even than you think. pkg-config
is flat-out abandonware -- and this is provable, because it does not
actually build from source. Check out
https://gitlab.freedesktop.org/pkg-config/pkg-config/-/issues/55

Note: this is due to their use of embedded glib, which breaks due to
internal macro clashes.

- They cannot update glib, because glib no longer uses autotools.

- They cannot drop the bundled glib, because glib mandatorily requires
  pkg-config to build.

- They cannot rewrite pkg-config to stop using glib functionality,
  because that would imply anyone is maintaining it, and the last
  functional changes were from 2019, and the last non-functional
  documentation changes were from January 2021 -- the very same day that
  the "fails to build" bug was *closed* with the message "hopefully you
  found the answer" alongside "If you're building from a tarball, you
  don't need to run the autogen script". Radio silence since then.


Fortunately, only the freedesktop.org version ever had a bootstrap
problem to begin with.


-- 
Eli Schwartz
Reply to thread Export thread (mbox)