Looking at this, from a trunk build:
$ tail -1 apr.pc
Cflags: -DDARWIN -DSIGPROCMASK_SETS_THREAD_MASK -g -O2 -I${includedir}
$ ./apr-2-config --cflags
-g -O2
or from APR installed by Homebrew on macOS:
$ /opt/homebrew/opt/apr/bin/apr-1-config --cflags
-g -O2 -Wall
$ tail -1 /opt/homebrew/opt/apr/lib/pkgconfig/apr-1.pc
Cflags: -DDARWIN -DSIGPROCMASK_SETS_THREAD_MASK -g -O2 -Wall -I${includedir}
(note that MacPorts evidently takes the trouble to remove those flags
from the results.)
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?
The culprit seems to be our construction of CFLAGS, then copying them
wholesale to EXTRA_CFLAGS, which then get interpolated into the
pkg-config file and the apr-X-config scripts. What, exactly, is the
point of that interpolation? If it's to pass flags that were set
explicitly at configure or build time, then that clearly is not how its
implemented, because setting CFLAGS for configure removes them from
apr-X-config and the pkg-config file.
My knee-jerk reaction was to just stop interpolating EXTRA_CFLAGS, but
then, I've no clue what that would break. Someone with a deeper
understanding of the autotools build, please speak up. I'm happy to dig
into the build code to get this fixed, but I would appreciate a place to
start; not just on trunk but the 1.7 and 1.8 branches, too.
-- Brane
