unofficial mirror of
 help / color / mirror / code / Atom feed
From: Ryan Schmidt <>
To: David Bremner <>
Subject: Re: Fix order of -I and -L flags
Date: Tue, 21 Dec 2021 01:33:03 -0600	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

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
> 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]:
>> 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.

  reply	other threads:[~2021-12-21  8:00 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-12-17  1:08 Ryan Schmidt
2021-12-17 13:45 ` David Bremner
2021-12-20 21:21   ` Tomi Ollila
2021-12-20 22:58     ` David Bremner
2021-12-21  7:33       ` Ryan Schmidt [this message]
2021-12-24 18:29     ` [PATCH 1/3] build: move LDFLAGS after notmuch libraries David Bremner
2021-12-24 18:29       ` [PATCH 2/3] build: move CPPFLAGS after source directory includes David Bremner
2021-12-24 18:29       ` [PATCH 3/3] build: move {C,CXX}FLAGS to the end of FINAL_{C,CXX}FLAGS David Bremner
2021-12-29 18:14       ` [PATCH 1/3] build: move LDFLAGS after notmuch libraries Tomi Ollila
2021-12-31 11:12       ` David Bremner

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

  List information:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \
    --subject='Re: Fix order of -I and -L flags' \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

Code repositories for project(s) associated with this inbox:

	notmuch.git.git (no URL configured)

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).