Tomi Ollila <tomi.ollila@iki.fi> writes: > On Fri, Dec 17 2021, David Bremner wrote: >> >> Although I don't consider GNU standards normative for notmuch, there is >> some value in doing things a standard way. In particular the way notmuch >> uses {C,CPP,LD,CXX}FLAGS follows e.g. [1]. > > Does it ? > > I initially thought CFLAGS should be first so that user can modify > anything, but then I thought that CFLAGS should be last just so that > the "project internal" includes are taken first. > "Put CFLAGS last in the compilation command, after other variables > containing compiler options, so the user can use CFLAGS to override the > others. " That's a good point. I was thinking about CPPFLAGS, because of Ryan's original question(s). > > ^^ that would also say mean that the -I's and -L's given in ${CFLAGS} > would be effective after the -I's and -L' configured... > >> >> I guess on the Linux / BSD side we expect the configure script to do the >> heavy lifting so that manual setting of CPPFLAGS / LDFLAGS at build time >> is not needed in general. So one question is why isn't this the case for >> macports? >> >> I think there is value in letting individual end-users use these >> variables to override things (we just saw a case the other day where >> that fixed someone's unique build problem). > > What was the case ? > using LDFLAGS id:87lf0thhft.fsf@tethera.net I have to admit I'm a bit fuzzy on how LDFLAGS work. I would imagine that -L works left to right like -I, but I'm too lazy to check right now. >> I'm open to ideas for how we can make things easier for macports without >> taking away existing functionality for other users. > > Would putting CFLAGS last break someone's workflow? Did I understand > correctly what [1] mean for use of CFLAGS ? > I think you're right, but I think it won't help Ryan. >> >> [1]: https://www.gnu.org/prep/standards/html_node/Command-Variables.html. > > > Tomi _______________________________________________ notmuch mailing list -- notmuch@notmuchmail.org To unsubscribe send an email to notmuch-leave@notmuchmail.org