From owner-freebsd-python@FreeBSD.ORG Thu Dec 5 20:04:51 2013 Return-Path: Delivered-To: freebsd-python@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A27BA432; Thu, 5 Dec 2013 20:04:51 +0000 (UTC) Received: from duck.symmetricom.us (duck.symmetricom.us [206.168.13.214]) by mx1.freebsd.org (Postfix) with ESMTP id 58C03178D; Thu, 5 Dec 2013 20:04:51 +0000 (UTC) Received: from gromit.timing.com (gromit.timing.com [206.168.13.209]) by duck.symmetricom.us (8.14.6/8.14.6) with ESMTP id rB5K4okb079464; Thu, 5 Dec 2013 13:04:50 -0700 (MST) (envelope-from jhein@symmetricom.com) Received: from gromit.timing.com (localhost [127.0.0.1]) by gromit.timing.com (8.14.7/8.14.5) with ESMTP id rB5K4VVt039698; Thu, 5 Dec 2013 13:04:31 -0700 (MST) (envelope-from jhein@gromit.timing.com) Received: (from jhein@localhost) by gromit.timing.com (8.14.7/8.14.7/Submit) id rB5K4UV8039697; Thu, 5 Dec 2013 13:04:30 -0700 (MST) (envelope-from jhein) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <21152.56398.613937.600936@gromit.timing.com> Date: Thu, 5 Dec 2013 13:04:30 -0700 From: John Hein To: bug-followup@FreeBSD.org Subject: Re: ports/184339: lang/python27 does not allow unsetting NLS (or other options) In-Reply-To: <201312051454.rB5EsC1o051327@freefall.freebsd.org> References: <201312051454.rB5EsC1o051327@freefall.freebsd.org> X-Mailer: VM 8.2.0b-trunk-1484 under 24.3.1 (i386-portbld-freebsd8.3) Cc: gerald@pfeifer.com, koobs@FreeBSD.org, freebsd-python@FreeBSD.org X-BeenThere: freebsd-python@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: FreeBSD-specific Python issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Dec 2013 20:04:51 -0000 It's something of a complicated interaction. But the reason you see a difference in lang/python27 vs. say, lang/gcc boils down to having OPTIONS_FILE_SET+=NLS in the saved options file _and_ NLS in OPTIONS_DEFINE. If so, bsd.options.mk overrides the WITHOUT_NLS setting. This could be considered a bug, but maybe it's just somewhat unexpected. koobs' comment is correct but slightly incomplete - WITHOUT_NLS loses to the options file even if set in the port's Makefile or make.conf, not just the command line. And it's not clear that the deprecation (which is not clearly documented that I could find - but I could have missed where it is spelled out) is meant to apply to settings in Makefile / make.conf. I could see this being an issue for a slave port that explicitly sets WITHOUT_XXX to override a master port option setting. Probably the right thing in that case is to use a mechanism to exclude XXX from the master's OPTIONS list when building the slave port. Anyway, it's not obvious to me that the options file should override WITH_*/WITHOUT_* settings or vice versa. It's not apparent that a setting in the options file should override make.conf. Maybe the option file setting should have a choice to "obey any global setting first" for a particular option in addition to just allowing it to be set or unset. Having WITHOUT_* work in some cases but not others consistently seems like a potential source of confusion if the rules are not spelled out clearly. As far as python27, I'm not sure why NLS is in the OPTIONS_DEFINE list instead of just relying on the fact that NLS is a global option. As far as I understand it, NLS could be removed from OPTIONS_DEFINE for python27 (& other pythonXY ports). It has a slightly different NLS_DESC than the default option, but I'm not sure that nuanced distinction is important in this case. Unless there's a good reason I'm missing to have NLS in OPTIONS_DEFINE, I'd vote on removing it from OPTIONS_DEFINE in python* (and EXAMPLES and IPV6, too, I suppose).