Re: meson advice on CFLAGS et al.

["Dr. Thomas Orgis" <thomas.orgis%uni-hamburg.de@localhost>]

Am Tue, 21 Jul 2026 18:44:36 +0200
schrieb Thomas Klausner <wiz%netbsd.org@localhost>:

> The meson documentation says to _not_ use CFLAGS, CXXFLAGS, LDFLAGS
> (and some more), but to use meson command line arguments instead.
> 
> https://mesonbuild.com/Reference-tables.html#language-arguments-parameter-name

You meant

	https://mesonbuild.com/Reference-tables.html#compiler-and-linker-flag-environment-variables
and
	https://mesonbuild.com/Reference-tables.html#compiler-and-linker-selection-variables

right?

While offering command-line parameters to override defaults from the
_standard_ environment variables* is fine and offers fine-grained
control, I very much object to this attitude. This brings meson back
far down on the list of build systems I'd like to employ myself (not a
huge list, I got other things to do;-).

Doing a simple build on the current system for the current system
should just involve calling the build tool and having compiler flags
from customary environment variables in effect, like the compilers
themselves (if compiling C and a variable CC is set, please use that as
compiler if not instructed otherwise).

It is a major PITA, IMHO, for packaging or just scripted building that
build systems think they're defining the world and anything else
doesn't matter.

I'd understand dropping this

	Since 0.54.0, Following Autotool and other legacy build
	systems, environment variables that affect machine-specific
	settings come in pairs: for every bare environment variable
	FOO, there is a suffixed FOO_FOR_BUILD, where FOO just affects
	the host machine configuration, while FOO_FOR_BUILD just
	affects the build machine configuration.

But even here, they felt forced to support the cross-compiling
variables from autotools (not sure how widespread the _FOR_BUILD ones
are) and probably will keep them. The introducing wording really is
off, IMHO:

	It is recommended that you *do not use these*. They are
	provided purely to for backwards compatibility with other build
	systems.

While definite specification via command like and configuration is more
fine-grained and they're fine to recommend that, these scare words are
off. And it's not backward. It is for compatibility with an established
practice of other build systems, here to stay. Play well with others
and watch your language, you little prick.***

There's so much beauty in being able to set a set of well-known
environment variables and have them picked up without having to
dive into the specifics of build systems. There are situations where
you'd rather avoid overarching environment variables, but that is for
the user/admin/packager to decide.

> Using this did actually fix passing the linker flags for
> graphics/geeqie, so I wonder if we should set c_args, c_link_args,
> cpp_args, and cpp_link_args in meson/build.mk by default.

Isn't it a bug in the build system that LDFLAGS** didn't get through?
Pkgsrc might go that way in any case since it does have specific meson
handling, but I very much would like not to encourage upstream to
further deprecate the environment variables at least as _defaults_ that
can be overridden.

What caused the failure in this case? The meson docs still suggest that
it does pick up the environment variables … just that they don't like
it. I'd like to see the underlying issue in the build fixed,
independently of pkgsrc meson.mk adopting the suggested changes to use
the specific command like arguments.


Alrighty then,

Thomas


* Could move from FFLAGS to FCFLAGS, as Open-MPI insists, it's not
  _really_ a standard, but damn looks like one.

** Not to mention LD_RUN_PATH not being nuked by builds deciding to add
   rpath flags when not being called for … but OK, for that, one folds
   LD_RUN_PATH into -Wl,-rpath and puts it into LDFLAGS before building
   …

*** Word colouring just for illustration purposes. Please don't be
    offended, whoever gets offended.

-- 
Dr. Thomas Orgis
HPC @ Universität Hamburg