Re: Fix order of -I and -L flags
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@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.
___
notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send an email to notmuch-le...@notmuchmail.org
Re: Fix order of -I and -L flags
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@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
___
notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send an email to notmuch-le...@notmuchmail.org
Re: Fix order of -I and -L flags
On Fri, Dec 17 2021, David Bremner wrote:
> Ryan Schmidt 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
Re: Fix order of -I and -L flags
Ryan Schmidt 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].
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).
I'm open to ideas for how we can make things easier for macports without
taking away existing functionality for other users.
d
[1]: https://www.gnu.org/prep/standards/html_node/Command-Variables.html.
___
notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send an email to notmuch-le...@notmuchmail.org
