From owner-cvs-all@FreeBSD.ORG Fri Jun 17 17:59:55 2011 Return-Path: Delivered-To: cvs-all@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6C342106566C; Fri, 17 Jun 2011 17:59:55 +0000 (UTC) (envelope-from bf1783@googlemail.com) Received: from mail-pz0-f54.google.com (mail-pz0-f54.google.com [209.85.210.54]) by mx1.freebsd.org (Postfix) with ESMTP id 046A68FC08; Fri, 17 Jun 2011 17:59:54 +0000 (UTC) Received: by pzk27 with SMTP id 27so2683996pzk.13 for ; Fri, 17 Jun 2011 10:59:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:reply-to:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=Hsy26YwUP8qtbNno5hFzjN91tgUFMDXBjcD2nIfaEUk=; b=AG28rTGVj+Rq7v25H32ZSEbfd9HgOe/qrhiqeRY4//SiSl5uUm1H9IEsxynXGOEYwl c8nj51H23xwSrR12YXVp/lEMQZlj5rG+B9XPp+f+KTjjDkjIh0W+q/5A4J2IDfufaqiH wku8HPE6EuY5KKrY2lm7T0BvyQVnjI48tqSY4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; b=ZmNPAqdTk7YYMPPMQwAsssPFYIyLKEDpUWxBfPPrUieO9jjkhVR/0/mT+l139Ca9K/ 29K1VHbmO7USscuKDI6mfXtoJK5o/QsEi4H85SgC8m04s1YAYFP38XPR54yiqyTNMVRJ r/VdtXp8cYcfIxJLKSAOICzNO6SK6hWoFNtnQ= MIME-Version: 1.0 Received: by 10.68.43.193 with SMTP id y1mr1150874pbl.168.1308333594319; Fri, 17 Jun 2011 10:59:54 -0700 (PDT) Received: by 10.68.40.7 with HTTP; Fri, 17 Jun 2011 10:59:53 -0700 (PDT) In-Reply-To: <64E6CAE2-1B3E-4A12-8103-1984DA9BB1E0@tandon.net> References: <201106160842.p5G8gS6T054738@repoman.freebsd.org> <20110616164733.GA40181@FreeBSD.org> <20110617004742.GD19139@magic.hamla.org> <0C0893AE-B699-4DAB-AD58-C6075349DC2F@tandon.net> <64E6CAE2-1B3E-4A12-8103-1984DA9BB1E0@tandon.net> Date: Fri, 17 Jun 2011 17:59:53 +0000 Message-ID: From: "b. f." To: Sahil Tandon Content-Type: text/plain; charset=ISO-8859-1 Cc: Alexey Dokuchaev , Sahil Tandon , Wen Heping , "cvs-all@freebsd.org" , "ports-committers@freebsd.org" , "cvs-ports@freebsd.org" Subject: Re: cvs commit: ports/sysutils/tmux Makefile X-BeenThere: cvs-all@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: bf1783@gmail.com List-Id: **OBSOLETE** CVS commit messages for the entire tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jun 2011 17:59:55 -0000 On 6/17/11, Sahil Tandon wrote: > On Jun 17, 2011, at 10:43 AM, "b. f." wrote: > >> On 6/17/11, Sahil Tandon wrote: >>> On Jun 16, 2011, at 11:57 PM, "b. f." wrote: >>> >>>> On 6/17/11, Sahil Tandon wrote: >>>>> On Thu, 2011-06-16 at 16:47:33 +0000, Alexey Dokuchaev wrote: >>>>> >>>>>> On Thu, Jun 16, 2011 at 08:42:28AM +0000, Wen Heping wrote: >>>>>>> wen 2011-06-16 08:42:28 UTC >>>>>>> >>>>>>> Modified files: >>>>>>> sysutils/tmux Makefile >>>>>>> Log: >>>>>>> - Fix build when CFLAGS is set in /etc/make.conf >>>>>> >>>>>> Hmm, default CPPFLAGS is empty. Judging just from the diff, instead >>>>>> of >>>>>> introducing EXTRA_CPPFLAGS, setting CPPFLAGS instead of CFLAGS (which >>>>>> is >>>>>> bogus in the first place: -I is preprocessor flag) should be enough >>>>>> (no >>>>>> MAKE_ENV adjustment and extra REINPLACE_CMD hack would be required in >>>>>> this >>>>>> case as well). I am missing something obvious here? >>>>> >>>>> Because of the way upstream Makefile handles CPPFLAGS, it is not so >>>>> straightforward. This was discussed on freebsd-ports: >>>>> >>>>> http://lists.freebsd.org/pipermail/freebsd-ports/2011-June/068218.html >>>>> http://lists.freebsd.org/pipermail/freebsd-ports/2011-May/067930.html >>>> >>>> But this does not seem so different from the many other ports that set >>>> or alter variables in the port Makefile. If a user overrides these >>>> changes in an automatically and recursively-included Makefile like >>>> __MAKE_CONF, or on the command-line, it it the user's problem. Users >>>> should not pollute their port builds by unconditionally defining >>>> variables in __MAKE_CONF, and I don't think that we should add >>>> elaborations to ports to avoid such mistakes. >>> >>> Yes and I think we get that and I personally agree with your sentiment; >>> however, I'm not sure that means maintainers need to revert commits that >>> were done to prevent users from shooting their own foot. >> >> Yes, but the proper anti-foot-shooting measure, is not to make >> sysutils/tmux and the thousands of other ports that may be affected by >> this blunder unnecessarily complicated, but, since we keep running >> into this problem, to add comments to the Handbook and to >> src/share/examples/etc/make.conf, to explain that users should not >> _unconditionally_ define variables that may affect a port build in >> __MAKE_CONF, even CFLAGS, because the file may be automatically >> included several times when make is called recursively, clobbering >> changes made to those variables in Makefiles that are not last in a >> chain of recursions. If we were to follow your argument to it's >> logical conclusion, we would have to remove CPPFLAGS+= and CPPFLAGS= >> statements in every port that uses them and replace them with a >> variable that we think is less likely to be defined in a user's >> __MAKE_CONF, and then manually patch all distfile Makefiles where >> appropriate. The amount of work involved would be enormous, and it >> still wouldn't be completely foolproof. There is no point in putting >> 50 kg. of armor on every user's arms and legs to prevent any user from >> shooting himself, if a number of users are just as likely to direct >> the gun to their unarmored heads. I say keep the choice of variables >> in port Makefiles simple and uniform, and the patching to a minimum. > > I think your passion about this "issue" is sweet. My (incredibly simple) > point is that unless we have a consensus, then going through and reverting > the tmux commit is really not needed. If you strongly believe what you've > gone on about above, so much so as to send related patches for the handbook > and all ports that could be peripherally impacted, that is a commendable > undertaking and I don't think anyone would oppose it. I did not suggest or > even remotely insinuate that anything be changed in ports that directly set > CPPFLAGS so please avoid straw men misrepresentations in your follow-ups. Look, I don't mean to sound overly-exercised about this particular commit -- that's easy to do in email when there is a lack of other verbal and non-verbal cues --- of course it doesn't _need_ to be reverted, although it would be better if it were. Nor did I mean to suggest that in this particular instance you were arguing for sweeping changes. I was merely pointing out the flaws in the reasoning behind the change, and the undesirability of making many such unnecessary ad hoc changes of this kind over time. The real issue (since this problem has come up in multiple PRs, and email and forum threads, I don't enclose it in quotes) is that users (including committers -- the person who filed the original PR behind this change is a src committer, and others have made similar mistakes), are being misled by examples in the base system sources into abuses of __MAKE_CONF, and are breaking port builds. I have previously suggested adding comments to /src/share/examples/etc/make.conf to point out this problem, but no one took up my suggestion, and I can't do it myself because I don't have a src commit bit. I guess that I'll have to try again. b.