Subject: Re: mk.conf & PKGNAME/PKGBASE
To: David Brownlee <>
From: Quentin Garnier <>
List: tech-pkg
Date: 09/20/2005 13:33:03
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Tue, Sep 20, 2005 at 12:04:45PM +0100, David Brownlee wrote:
> 	There is currently no way for mk.conf to know the package that
> 	is currently building, as there is no guarantee that PKGNAME or
> 	PKGBASE are set by that point. cpuflags' needs
> 	to know the PKGBASE to determine which flags to exclude from a
> 	build, and it does so by trying to look at PKGBASE, PKGNAME,
> 	and DISTNAME, but since packages are free to change PKGNAME after
> 	mk.conf has been included this cannot work all the time.
> 	Some suggestions:
> 	1) Mandate that PKGNAME & PKGBASE must be set before including
> 	   mk.conf (potentially even add some code to store them away
> 	   just before including mk.conf and a line to test they have
> 	   not subsequently been changed in the 'build' target)
> 	2) If mk.conf sets an appropriate variable then include it
> 	   again later to after PKGBASE has definitely been set
> 	3) Add another config file included at the right point
> 	4) Live with the brokenness.
> 	I'm inclined towards 1)

How can 1. be possible?  Consider the python packages.  You might
select a precise version of Python in mk.conf, therefore the final name
of the python module/application package can't be known until the
actual python version used is defined.

Can't you use .CURDIR?

Quentin Garnier - -
"When I find the controls, I'll go where I like, I'll know where I want
to be, but maybe for now I'll stay right here on a silent sea."
KT Tunstall, Silent Sea, Eye to the Telescope, 2004.

Content-Type: application/pgp-signature
Content-Disposition: inline

Version: GnuPG v1.2.6 (NetBSD)