From owner-cvs-all@FreeBSD.ORG Mon Mar 29 08:21:32 2010 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 1799A1065672; Mon, 29 Mar 2010 08:21:32 +0000 (UTC) (envelope-from stas@FreeBSD.org) Received: from mx0.deglitch.com (backbone.deglitch.com [IPv6:2001:16d8:fffb:4::abba]) by mx1.freebsd.org (Postfix) with ESMTP id 838018FC0A; Mon, 29 Mar 2010 08:21:31 +0000 (UTC) Received: from sputnik.SpringDaemons.com (c-67-188-12-68.hsd1.ca.comcast.net [67.188.12.68]) by mx0.deglitch.com (Postfix) with ESMTPA id 1AEF68FC52; Mon, 29 Mar 2010 12:21:28 +0400 (MSD) Received: from sputnik.SpringDaemons.com (localhost [127.0.0.1]) by sputnik.SpringDaemons.com (Postfix) with SMTP id A9B19B874; Mon, 29 Mar 2010 01:22:33 -0700 (PDT) Date: Mon, 29 Mar 2010 01:22:33 -0700 From: Stanislav Sedov To: Peter Pentchev Message-Id: <20100329012233.d7c2093a.stas@FreeBSD.org> In-Reply-To: <20100329074634.GA1315@straylight.m.ringlet.net> References: <201003221056.o2MAu4D5001930@repoman.freebsd.org> <20100326192300.25171ab9.stas@FreeBSD.org> <20100329074634.GA1315@straylight.m.ringlet.net> Organization: The FreeBSD Project X-XMPP: ssedov@jabber.ru X-Voice: +7 916 849 20 23 X-PGP-Fingerprin: F21E D6CC 5626 9609 6CE2 A385 2BF5 5993 EB26 9581 X-Mailer: carrier-pigeon Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: cvs-ports@FreeBSD.org, cvs-all@FreeBSD.org, ports-committers@FreeBSD.org Subject: Re: cvs commit: ports/dns/c-ares Makefile distinfo pkg-plist ports/dns/c-ares/files ares-config-info.patch patch-Makefile.in X-BeenThere: cvs-all@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: **OBSOLETE** CVS commit messages for the entire tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Mar 2010 08:21:32 -0000 On Mon, 29 Mar 2010 10:46:34 +0300 Peter Pentchev mentioned: > Hmmm, apologies if I'm missing something here - and it would not be > a big surprise to me if I was, even about such an important thing > about the package building cluster :\ However, IMHO the need to > check for WITHOUT_* in the case of "default to on" is somewhat > a thing of the past - I think that the current options handling code > will define the WITH_* symbol if there is no options file and this is > an automated build. > > [roam@straylight /usr/ports/dns/c-ares]$ make -V OPTIONSFILE > /var/db/ports/c-ares/options > [roam@straylight /usr/ports/dns/c-ares]$ ls -l "`make -V OPTIONSFILE`" > ls: /var/db/ports/c-ares/options: No such file or directory > [roam@straylight /usr/ports/dns/c-ares]$ make -V WITH_HIDE_SYMBOLS > true > [roam@straylight /usr/ports/dns/c-ares]$ make BATCH=yes -V WITH_HIDE_SYMBOLS > true > [roam@straylight /usr/ports/dns/c-ares]$ make PACKAGE_BUILDING=yes -V WITH_HIDE_SYMBOLS > true > [roam@straylight /usr/ports/dns/c-ares]$ make BATCH=yes PACKAGE_BUILDING=yes -V WITH_HIDE_SYMBOLS > true > [roam@straylight /usr/ports/dns/c-ares]$ make BATCH=yes PACKAGE_BUILDING=yes -V WITH_HIDE_SYMBOLS -V CONFIGURE_ARGS:M'*symbol*' > true > --enable-symbol-hiding > [roam@straylight /usr/ports/dns/c-ares]$ > > Am I wrong in assuming that any automatically-built packages would > have BATCH and/or PACKAGE_BUILDING defined at build time, and that > the code in bsd.port(.pre).mk would use the default value for all > options in that case? Or is there some defined symbol - or some other > combination of symbols - that would result in WITH_HIDE_SYMBOLS > *not* being defined, even though the option's default is "yes"? > > Of course, I could be missing something, in which case I'd be thankful > for a correction in my worldview :) > Sorry, my bad. It seems you're right and it works fine here. Sorry for the noise. However, I noticed it doesn't work universally. If you take a look at the security/openconnect port, for example, that has the same problem (and apparently was not tested at all), and try to look what LIB_DEPENDS contains (make -V LIB_DEPENDS) you will notice it always pulls gtk into depends regardless of the GUI option value. It appears that we should be careful with options checking even in this century :-) Again, sorry for the noise. :-) -- Stanislav Sedov ST4096-RIPE