On 11. 8. 25 11:53, Joe Orton wrote:
On Thu, Aug 07, 2025 at 04:54:09PM +0200, Branko Čibej wrote:
Why? Why are we telling our library consumers about debugging, optimisation
and warning flags? This makes no sense to me and is actively detrimental. In
Serf, for example, we go through extra hoops to remove this crud from the
APR flags; and I believe Subversion does something similar. APR should not
dictate how its consumers are compiled. The --cppflags, sure, those are
necessary on some platforms in order to make the resulting linked code work;
but --cflags?
Not sure I can answer all of this and don't want to defend the current
design particularly, but:
In general, how do you distinguish "debugging, optimisation and warning"
flags from compiler flags which might impact ABI choices at cc or libc
level? e.g. -DNDEBUG is a "debugging flag." but -D_FILE_OFFSET_BITS=64
is a libc ABI choice. -O2 is a optimisation flag, for *bsdi* in the
hints, -m486 is... possibly an ABI choice?
In this particular case, it shouldn't be that hard: configure adds -g,
-O2, and possibly -Wall itself, so all we need to do is make sure those
flags are used for building but not for configuring consumers. Things
like -D_FILE_OFFSET_BITS=64 or -DREENTRANT or -D_GNU_SOURCE are added to
--cppflags, etc. User-supplied flags are _not_ exported, so getting some
kind of cross-compilation to work with a whole stack of packages is, I
guess, a bit more involved?
Historically part of the problem APR solved was "pick a set of compiler
flags for weird Unix platforms which give me a compiler which DTRT, and
apply them everywhere". So, CFLAGS was part of that. There was/is a
blurred line between "picking good defaults" and allowing users to
pick/override those, and this stuff was not really designed/documented
in sufficient detail.
Yes, I gathered as much from reading the code...
(Building on 32-bit Linux with -D_FILE_OFFSET_BITS=64 and on 64-bit
platforms with gcc -m32 were always two good tests of ABI consistency
via inherited $CC or $CFLAGS/$CPPFLAGS)
Well, this is a good start. It's tricky that we don't seem to have a
mechanism for the user to set ABI-related flags in such a way that we
end up exporting them from the config, but that's a whole other issue. I
suppose we'll have to split the EXTRA_CFLAGS in two -- one for internal
consumption and one for exported configuration. This will be tricky
with, as you note, all the copious documentation. :)
-- Brane
