Re: Standardizing NO_NETWORK and USE_SYSTEM_DEPS environment variables

[Bruno Haible <bruno@clisp.org>]

Michał Górny wrote:
> The problem with explicit options

The problems with your environment variable proposal are that:

  1) You can't just shove your desired way of doing things into
     build systems that originated from 1995 to 2025, that are file-based
     or network-based (like npm or cargo), that have unit tests in the
     source files or in specific files, etc.

  2) Environment variable values don't appear in the logs, while command
     line invocations typically do. Thus a developer would wonder "why
     does this build behave differently than on my machine?", creating
     LOTS of headaches.

> is that 1) they are different for every build system
> 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=false for Meson,
> -DNETWORK=OFF for CMake and probably a dozen more.

Yeah. Face it. There is no magic wand that will make wide varieties
of build systems work alike.

> 2) they require explicit support checks,
> 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.

Yes. A fact of life as well: Not all packages can be configured in the
same way. And yes, although the './configure --help' of some package
may show an option, occasionally such an option does not work.

If you want a distro will very small per-package configuration, look at
T2SDE.

> and 3) they
> assume you have an explicit control over the build command-line.
> 
> 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.

Yes: If someone has added layers over a package's build system ('ebuild'
or whatever), that layer ought to make sure it doesn't prohibit configuration
possibilities on the way. That layer is not proprietary; so, you ought to
be able to fix that.

Bruno