On Fri, Dec 17 2021, David Bremner wrote: > Ryan Schmidt <notm...@ryandesign.com> writes: > >> The notmuch build system puts -I and -L flags in the wrong order. >> >> Specifically, -I flags the user might specify in the CPPFLAGS >> environment variable appear before the -I flags for the project's own >> directories, resulting in build failure if a previous version of >> notmuch (whose headers differ sufficiently from the new version) was >> already installed. >> >> https://trac.macports.org/ticket/63274 >> >> Similarly, -L flags the user might specify in the LDFLAGS environment >> variable appear before the -L flags for the project's own directories, >> resulting in build failure if a previous version of notmuch (whose >> libraries differ sufficiently from the new version) was already >> installed. >> >> https://trac.macports.org/ticket/63665 > > 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. 2 things) (1) I was wrong with where user can modify anything: -I's, -L's in c compiler options are used in order, but (OTOH) (probably) some other options given later may override previously given option. then (2) [1] seems to say that "Put CFLAGS last in the compilation command, after other variables containing compiler options, so the user can use CFLAGS to override the others. " ^^ 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 ? > 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 ? > > d > > [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-le...@notmuchmail.org