On Fri, Dec 17 2021, David Bremner wrote:
> Ryan Schmidt <[email protected]> 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 -- [email protected]
To unsubscribe send an email to [email protected]
