Re: Standardizing NO_NETWORK and USE_SYSTEM_DEPS environment variables

Michał Górny <[email protected]> Thu, 23 Jan 2025 15:26:18 +0100
Newsgroups dev.linux.lists.distributions
Organization Gentoo
Message-ID <[email protected]>
--=-qi08h7Di8OkPeFvjUKy2
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Thu, 2025-01-23 at 14:50 +0100, Bruno Haible wrote:
> Micha=C5=82 G=C3=B3rny wrote:
> > 2) USE_SYSTEM_DEPS -- if it's set to a non-empty value, it requests tha=
t
> > the build system does not use any vendored dependency for which it
> > supports using a system version instead, and that it links to shared
> > libraries whenever possible.
>=20
> This contradicts the GNU Coding Standards [1]. For GNU packages,
> configuration of such things should be done through --with-* and --withou=
t-*
> options. NOT through environment variables.
>=20
> Proposing something that contradicts the GNU Coding Standards is a non-st=
arter.
>=20

The problem with explicit options is that 1) they are different for
every build system, 2) they require explicit support checks, and 3) they
assume you have an explicit control over the build command-line.

The first problem means that we simply can't standardize of anything
like that.  Even if we agreed on a single name, you'd have --disable-
network and --without-network for autoconf, -Dnetwork=3Dfalse for Meson,
-DNETWORK=3DOFF for CMake and probably a dozen more.

The second problem is that we can't simply enable it unconditionally
and be done with it.  In Gentoo, we already do the messy thing of
checking --help output to determine if we can pass stuff like --disable-
shared, and that has already backfired.

The third problem goes much deeper.  I largely come from a Python
background.  The most problematic packages I work with generally involve
something like a PEP517 backend calling setup.py calling CMake, which
in turn may involve some subprojects.  Having an explicit option means
that I need to ask everyone to add an explicit option at every layer,
and ensure that the option is passed down.  And that's assuming that we
are dealing with layers that actually can accept options, which is not
always true.  We aren't living in a perfect world.

Just to be clear, I do not mind at all having explicit options to do
this.  I'm just saying that having these options default based
on environment variables would be very helpful, and make things much
easier.  They mean we can just unconditionally set NO_NETWORK=3D1
and USE_SYSTEM_DEPS=3D1, and with some luck, it will just work and make
our lives easier, and in the worst case it won't do any harm.

--=20
Best regards,
Micha=C5=82 G=C3=B3rny


--=-qi08h7Di8OkPeFvjUKy2
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part

-----BEGIN PGP SIGNATURE-----

iQFGBAABCgAwFiEEx2qEUJQJjSjMiybFY5ra4jKeJA4FAmeSUYoSHG1nb3JueUBn
ZW50b28ub3JnAAoJEGOa2uIyniQO5D0H/igDKjxUy5GAAgGcHCvopdAodF5yQCCU
hXZlv/7Wiiw5NgDgSVKaFaXgUOgybQWp7UYR1Wl9YxKBYfb1SjakjCijhv3QUO0B
zT6T+Mb0KqvCH7wBAJaHjrY2zE/IQzNEDH20XpUsOxvZBZIB//dqxoKu7RvMlITU
0aogALeJQuekZ2QetGriNLMoAPmUFZuMLztMcO1jA1alRJGuLkHF4uHQ7uHUWeGj
UdIaVOc8QoxJ3wiapO3LMICKexqKhaux0M3xloICwvo51ikG+C/92iq+U1wnN3EG
93kJ8IvOgQ9nwPinqGlraFJ2LF0tMoCKA+0RHZRu3MJAxlDY2vDu0zE=
=7FdW
-----END PGP SIGNATURE-----

--=-qi08h7Di8OkPeFvjUKy2--