Hello Omar.
Omar Polo wrote in
<28P1AX08SNCS0.30TJDZ4GTJ8IJ@venera>:
|Steffen Nurpmeso <stef...@sdaoden.eu> wrote:
|> Stuart Henderson wrote in
|> <yn2oicg+bo0dc...@bamboo.spacehopper.org>:
|>|On 2022/05/13 00:22, Steffen Nurpmeso wrote:
|>|> Since the S-nail port did not honour port CFLAGS for i think
|>|> years, i hope it is ok to go like this for some time.
|>|
|>|That was because nobody had noticed it. Ports policy is to honour CFLAGS.
|>
|> Sigh. Works just fine on CRUX and Alpine Linux ;)
|> Well i do not know. The Python Makefile.inc does a virtuous
|> dance, CRUX does "make EXTRA_CFLAGS="$CFLAGS"" after doing so (for
...
|well, I can't speak for crux nor alpine, but as a general rule we want
|to be in control of the CFLAGS the port uses when building. Sometimes
|one port slips, but that's the policy.
|
|If a compiler changes something (see for example the not too old clang
|issue regarding -fcommon) you want to be able to fix the fallout by
|tweaking the various Makefiles, not digging into every port build system
|and patching things.
OK i understand the desire to add additional flags per se.
|> Adding onto the environment's $CFLAGS the set of project's CFLAGS
|> is ok? I see what i can do tomorrow.
|
|in this case it's as simple as (from the port makefile)
|
| MAKE_FLAGS += CFLAGS="${CFLAGS}"
If you would be so kind to add at least -DNDEBUG i would be fine.
In fact i wanted to go the hard way and add an EXTRA_CFLAGS
mechanism, and patch it into the port, but for OpenBSD it is ok.
Note please also do LDFLAGS="${LDFLAGS}" then, because the
built-in ones use -pie, and that requires -fPIE in CFLAGS, which
we then cannot guarantee.
A possible next release of s-cdda will have an EXTRA_CFLAGS
mechanism, already committed.
|and if you're ok with that and sthen@ doesn't change his mind i'll
|import it.
Thank you very much.
--steffen
|
|Der Kragenbaer, The moon bear,
|der holt sich munter he cheerfully and one by one
|einen nach dem anderen runter wa.ks himself off
|(By Robert Gernhardt)
