From owner-cvs-ports@FreeBSD.ORG Fri Jun 17 17:27:01 2011 Return-Path: Delivered-To: cvs-ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 79F5A106566B; Fri, 17 Jun 2011 17:27:01 +0000 (UTC) (envelope-from sahil@tandon.net) Received: from spartan.hamla.org (spartan.hamla.org [206.251.255.30]) by mx1.freebsd.org (Postfix) with ESMTP id 4CD968FC18; Fri, 17 Jun 2011 17:27:01 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by spartan.hamla.org (Postfix) with ESMTP id EE8FB170F7; Fri, 17 Jun 2011 13:27:00 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=tandon.net; h= date:date:subject:subject:from:from:x-mailer:message-id :content-type:content-type:content-transfer-encoding :mime-version:in-reply-to:references:received:received; s=aegis; t=1308331620; bh=IJQ1DJ4k5KxqGP2Z5SOM78QVNnTjsbDbMPpEZPTEy3s=; b= HAO4XC1A9FZ0GfMw7/SWPmX08nIGTrQ7tDEQsGLPyoNWCTv2dVbbTnY86WuPmv46 ZrQkxX+OuZ6zCCxWwXXTwwiDaQWCdSIogXIPqm5YIIawS+m+1SKpBrf7riGaPrWA s3ARgSiLxNEpkZrh1eAS/ZoLaEMv4KBLKAI+JJ5gwvw= X-Virus-Scanned: by ClamAV at spartan.hamla.org Received: from spartan.hamla.org ([127.0.0.1]) by localhost (spartan.hamla.org [127.0.0.1]) (amavisd-new, port 10027) with LMTP id 6HDhSdqWwZCw; Fri, 17 Jun 2011 13:27:00 -0400 (EDT) Received: from [10.123.112.4] (mobile-166-137-138-047.mycingular.net [166.137.138.47]) by spartan.hamla.org (Postfix) with ESMTPSA id 12705170E6; Fri, 17 Jun 2011 13:26:53 -0400 (EDT) References: <201106160842.p5G8gS6T054738@repoman.freebsd.org> <20110616164733.GA40181@FreeBSD.org> <20110617004742.GD19139@magic.hamla.org> <0C0893AE-B699-4DAB-AD58-C6075349DC2F@tandon.net> In-Reply-To: Mime-Version: 1.0 (iPhone Mail 8C148a) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: <64E6CAE2-1B3E-4A12-8103-1984DA9BB1E0@tandon.net> X-Mailer: iPhone Mail (8C148a) From: Sahil Tandon Date: Fri, 17 Jun 2011 13:26:43 -0400 To: "bf1783@gmail.com" 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-ports@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: CVS commit messages for the ports tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jun 2011 17:27:01 -0000 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: >>=20 >>> On 6/17/11, Sahil Tandon wrote: >>>> On Thu, 2011-06-16 at 16:47:33 +0000, Alexey Dokuchaev wrote: >>>>=20 >>>>> On Thu, Jun 16, 2011 at 08:42:28AM +0000, Wen Heping wrote: >>>>>> wen 2011-06-16 08:42:28 UTC >>>>>>=20 >>>>>> Modified files: >>>>>> sysutils/tmux Makefile >>>>>> Log: >>>>>> - Fix build when CFLAGS is set in /etc/make.conf >>>>>=20 >>>>> Hmm, default CPPFLAGS is empty. Judging just from the diff, instead o= f >>>>> introducing EXTRA_CPPFLAGS, setting CPPFLAGS instead of CFLAGS (which i= s >>>>> bogus in the first place: -I is preprocessor flag) should be enough (n= o >>>>> MAKE_ENV adjustment and extra REINPLACE_CMD hack would be required in >>>>> this >>>>> case as well). I am missing something obvious here? >>>>=20 >>>> Because of the way upstream Makefile handles CPPFLAGS, it is not so >>>> straightforward. This was discussed on freebsd-ports: >>>>=20 >>>> http://lists.freebsd.org/pipermail/freebsd-ports/2011-June/068218.html >>>> http://lists.freebsd.org/pipermail/freebsd-ports/2011-May/067930.html >>>=20 >>> 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. >>=20 >> 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. >=20 > 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+=3D and CPPFLAGS=3D > 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) po= int 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 a= ll ports that could be peripherally impacted, that is a commendable undertak= ing and I don't think anyone would oppose it. I did not suggest or even rem= otely insinuate that anything be changed in ports that directly set CPPFLAGS= so please avoid straw men misrepresentations in your follow-ups.=