Re: Fix order of -I and -L flags

[Tomi Ollila <tomi.ollila@iki.fi>]

On Fri, Dec 17 2021, David Bremner wrote:

> Ryan Schmidt <notmuch@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