From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp1 ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms0.migadu.com with LMTPS id iNOMDayJwWEP1QAAgWs5BA (envelope-from ) for ; Tue, 21 Dec 2021 09:00:44 +0100 Received: from aspmx1.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp1 with LMTPS id OMIzCayJwWFZcQAAbx9fmQ (envelope-from ) for ; Tue, 21 Dec 2021 08:00:44 +0000 Received: from mail.notmuchmail.org (yantan.tethera.net [IPv6:2a01:4f9:c011:7a79::1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by aspmx1.migadu.com (Postfix) with ESMTPS id E865F2BC73 for ; Tue, 21 Dec 2021 09:00:43 +0100 (CET) Received: from yantan.tethera.net (localhost [127.0.0.1]) by mail.notmuchmail.org (Postfix) with ESMTP id 6F7AA5F708; Tue, 21 Dec 2021 08:00:39 +0000 (UTC) X-Greylist: delayed 1649 seconds by postgrey-1.36 at yantan; Tue, 21 Dec 2021 08:00:36 UTC Received: from smtprelay07.ispgateway.de (smtprelay07.ispgateway.de [134.119.228.97]) by mail.notmuchmail.org (Postfix) with ESMTPS id A4A945F6DA for ; Tue, 21 Dec 2021 08:00:36 +0000 (UTC) Received: from [67.198.113.253] (helo=untitled-mac-wifi.internal.macports.net) by smtprelay07.ispgateway.de with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1mzZd3-0007tc-UE; Tue, 21 Dec 2021 08:32:10 +0100 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.7\)) Subject: Re: Fix order of -I and -L flags From: Ryan Schmidt In-Reply-To: <875yrinas4.fsf@tethera.net> Date: Tue, 21 Dec 2021 01:33:03 -0600 Message-Id: References: <7851CAB5-4556-4931-A0A2-37003E56C927@ryandesign.com> <875yrnny4t.fsf@tethera.net> <875yrinas4.fsf@tethera.net> To: David Bremner X-Mailer: Apple Mail (2.3608.120.23.2.7) X-Df-Sender: MzY4ODE4 Message-ID-Hash: WZCFNQUULP2SWRMATNK4EOI7VAS5V6ND X-Message-ID-Hash: WZCFNQUULP2SWRMATNK4EOI7VAS5V6ND X-MailFrom: notmuch@ryandesign.com X-Mailman-Rule-Hits: nonmember-moderation X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-notmuch.notmuchmail.org-0 CC: notmuch@notmuchmail.org X-Mailman-Version: 3.3.3 Precedence: list List-Id: "Use and development of the notmuch mail system." List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Migadu-Flow: FLOW_IN X-Migadu-Country: DE ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1640073644; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:list-id:list-help: list-owner:list-unsubscribe:list-subscribe:list-post; bh=Xs7oT3Q1YKjYJWkrHcPhWR5uSTjIFyGuDmOIu2P+NYw=; b=SQjRrvaXHBvoILNlYmbd1CLjDKG+y9FrkfwblfJvTrhxofkoNboQHWzwZiKyXD03utrQdR 3ZfoRdgEBW+0qo0CTDpyZBimOH8rLFghqZLw/Zq0B8XliTdcs7jBklTXxCzSX+fmP/EKux +PtwsYormnAJVBgNRp77Pg+XPEsYbKYwF7ho2ohJUiD9MiH6XwCGQygbjVSacCJ9Mhw0+0 NzaWQoqRQWNoEwmCdEVHUEU5iLr7yueGo/NpOlwMT7E5dZYdClH9A8UpJWsU74YnihwLh/ 0VLxzornZZAQ2ZLcWtePdWiOiDvFcuCG1IhuKVg76o4KK4DtiJoBCoV+iwFWtg== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1640073644; a=rsa-sha256; cv=none; b=c05SszSAd4wXP7XmHlq/ev9msAalV8GrMOs1oAp0V5tzG/CnSE/eX6JGhNobiSwwPjLMRB c0Ie3jSZN828WnhfrA+NMwPho5tHB8JQ6yYQwNmahwEi1Rrv/nJMkOKpbIfASp9kuiiLv7 Eo0lc6cS8FoIxzepwxFjmEyCVR2g4YELrhKds8DOm5xC1L8CE/mQ0gfzzdQbG/RNS/bf16 UNs0u4y1gWn0sSSSYzlMaH6l4wxPvgypZJXJjVCfWtbeAJwGOKldXmapBOAk2usxg1+nIK OCUAy7lyRleaGW6X6HcXHS4wqFSGzN7zi1BTRkfhTcjlgiUQ8gTqG7WdvVM3cQ== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=none; dmarc=none; spf=fail (aspmx1.migadu.com: domain of notmuch-bounces@notmuchmail.org does not designate 2a01:4f9:c011:7a79::1 as permitted sender) smtp.mailfrom=notmuch-bounces@notmuchmail.org X-Migadu-Spam-Score: -2.43 Authentication-Results: aspmx1.migadu.com; dkim=none; dmarc=none; spf=fail (aspmx1.migadu.com: domain of notmuch-bounces@notmuchmail.org does not designate 2a01:4f9:c011:7a79::1 as permitted sender) smtp.mailfrom=notmuch-bounces@notmuchmail.org X-Migadu-Queue-Id: E865F2BC73 X-Spam-Score: -2.43 X-Migadu-Scanner: scn0.migadu.com X-TUID: EbYYOMzVhzeo 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.