From owner-cvs-src@FreeBSD.ORG Tue Apr 12 07:12:05 2005 Return-Path: Delivered-To: cvs-src@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BCE2D16A4CE; Tue, 12 Apr 2005 07:12:05 +0000 (GMT) Received: from smtp-1.dlr.de (smtp-1.dlr.de [195.37.61.185]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7355443D48; Tue, 12 Apr 2005 07:12:04 +0000 (GMT) (envelope-from Hartmut.Brandt@dlr.de) Received: from beagle.kn.op.dlr.de ([129.247.173.6]) by smtp-1.dlr.de over TLS secured channel with Microsoft SMTPSVC(5.0.2195.6713); Tue, 12 Apr 2005 09:12:02 +0200 Date: Tue, 12 Apr 2005 09:13:15 +0200 (CEST) From: Harti Brandt X-X-Sender: brandt_h@beagle.kn.op.dlr.de To: Greg 'groggy' Lehey In-Reply-To: <20050411230613.GL84649@wantadilla.lemis.com> Message-ID: <20050412090431.B75274@beagle.kn.op.dlr.de> References: <200504110720.j3B7KAIx034955@repoman.freebsd.org> <20050411101216.N97775@beagle.kn.op.dlr.de> <20050411230613.GL84649@wantadilla.lemis.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-OriginalArrivalTime: 12 Apr 2005 07:12:02.0961 (UTC) FILETIME=[ED253010:01C53F2E] cc: cvs-src@FreeBSD.org cc: src-committers@FreeBSD.org cc: cvs-all@FreeBSD.org cc: Kris Kennaway Subject: Re: cvs commit: src/usr.bin/make cond.c cond.h for.c for.h parse.c parse.h X-BeenThere: cvs-src@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Harti Brandt List-Id: CVS commit messages for the src tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Apr 2005 07:12:05 -0000 On Tue, 12 Apr 2005, Greg 'groggy' Lehey wrote: GgL>On Monday, 11 April 2005 at 2:11:26 -0700, Kris Kennaway wrote: GgL>> On Mon, Apr 11, 2005 at 11:07:28AM +0200, Harti Brandt wrote: GgL>> GgL>>> KK>I assume you've tested that this doesn't cause problems for anything GgL>>> KK>in the ports collection? GgL>>> GgL>>> I didn't test all of the ports collection - just a number of ports. But I GgL>>> grepped the ports infrastructure and the ports Makefile* for problematic GgL>>> constructs and found one problem that now shows up (under certain GgL>>> conditions) instead of beeing hidden: GgL>>> GgL>>> mail/dspam GgL>>> mail/dspam-devel GgL>>> GgL>>> both of them use GgL>>> GgL>>> . elseif ... GgL>>> GgL>>> This has been intepreted by make as a plain .else without any warning up GgL>>> to now. Now it is just ignored when the .if defined (WITH_MYSQL40) ... is GgL>>> false and give an error if it is true. I'll inform the maintainer about GgL>>> this. GgL>>> GgL>>> There may be of course ports that use our make to build. In any case the GgL>>> change to the .else and .endif clauses just give a warning so the ports GgL>>> maintainer have time to fix this. What could break is the use of GgL>>> .undefFOO but I don't expect many of them. GgL>> GgL>> I really hope this doesn't cause problems, but based on historical GgL>> precedent I expect that it will. In future, please coordinate GgL>> troublesome make changes with us (portmgr) so we can test them first GgL>> and avoid destabilizing the ports collection for the users. GgL> GgL>It would be interesting to understand the necessity of this change. GgL>We have so many different flavours of make already. This make Makefiles more debuggable. For an example see the dspam Makefile. It has a .elseif that silently is interpreted as .else. Now it gives a notice at least in some cases. This has nothing to do with different flavours of make. It is just a matter of writing .undef FOO instead of .undefFOO (which, I suppose, no one would have done on purpose anyway). Or .if defined(FOO) .else # defined(FOO) .endif # defined(FOO) instead of .if defined(FOO) .else defined(FOO) .endif defined(FOO) For the reader of the makefile .else defined(FOO) suggests that the expression is somehow used. In fact it isn't. If one reads: .else # defined(FOO) it is obvious that the expression is just a comment. harti