Re: Fix order of -I and -L flags

[Ryan Schmidt <notmuch@ryandesign.com>]

On Dec 20, 2021, at 16:58, David Bremner wrote:

> Tomi Ollila 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

Yes, following GNU standards is fine. I have not read them thoroughly but GNU standards surely say to behave the way I requested in my first message. MacPorts has no problem building most GNU projects that adhere to the standards.

Users (or package managers on their behalf) may specify things in CFLAGS, CXXFLAGS, CPPFLAGS, LDFLAGS that are required for their situation. Your build system must place its own flags of the equivalent type BEFORE anything in those user flags variables or else breakage can occur.

For example, a user (or for example MacPorts) may put -I/opt/local/include into CPPFLAGS to indicate that the build should search there for things it does not find in standard places. If you have any -I flags that your build specifies, for example to include files in your distribution (e.g. -Iinclude) you must put them BEFORE $(CPPFLAGS) otherwise user-specified directories will override your build directories which can result in build failure if for example an earlier version of notmuch is already installed.

Same goes for LDFLAGS flags. The user (or MacPorts) may specify -L/opt/local/lib in LDFLAGS. If you have any -L flags pointing to directories where you just built a library (e.g. -Llib), you must put those BEFORE user $(LDFLAGS) so that an already-installed notmuch library does not cause the build to fail.

Same goes for CFLAGS and CXXFLAGS. The user (or MacPorts) may specify -Os or some other optimization flag. If you want to set some optimization flag in your build, you must do so BEFORE user $(CFLAGS) or $(CXXFLAGS) so that the user can override your default optimization value.

Flags are processed in left to right order. For -I and -L flags, each flag specifies a directory in which to search for headers or libraries, respectively. If a file is not found in the first specified path, the second is tried, and so on. For -O optimization flags, the last specified flag takes effect.