[kde-freebsd] py27-pykde4-4.10.1

[Baptiste Daroussin]

On Tue, Apr 02, 2013 at 07:14:36PM +0200, Alberto Villa wrote:
> On Tuesday 02 April 2013 19:08:14 Baptiste Daroussin wrote:
> > OPTIONSFILE is built base on UNIQUENAME which is built which uses
> > PKGNAMEPREFIX.
> > 
> > that is the reason.
> 
> bsd.options.mk, line 194: the .if exists(${OPTIONSFILE}) tries to evaluate 
> (make(1) functions evaluate immediately, as you know), among other, 
> PKGNAMEPREFIX, which is not yet set because bsd.python.mk is included at line 
> 1424, while bsd.options.mk is included at line 1311 (speaking of bsd.port.mk). 
> Thus, OPTIONSFILE is not included.
> This was the case with bsd.qt.mk, at least, so I suspect it's the same.

Yes that true, and it is because OPTIONSFILE was (before optionsng) and still is
(with optionsng) built based on UNIQUENAME which is built base on PKGNAMEPREFIX.
cf bsd.port.mk L1286

So bsd.python.mk (it is not the only one) setting PKGNAMEPREFIX makes UNIQUENAME
not unique at all, first problem, it also make it changing meanng OPTIONSFILE
is expanded a first time to load options when PKGNAMEPREFIX is not yet set and
expanded a second time (when saving options) and PKGNAMEPREFIX is now set.

bsd.options.mk can't anyway be loaded after bsd.port.pre.mk given that one may
want to provide a PYTHON option and will make it set USE_PYTHON=yes for
example.

I don't know the right fix to be honnest. But UNIQUENAME not being UNIQUE is a
real problem imho and OPTIONSFILE changing depending on being after pre.mk or
before pre.mk is another problem.

I don't know what came first between the bsd.*.mk changing the PKGNAMEPREFIX and
UNIQUENAME creation, but for sure one choice here hasn't been smart.

regards,
Bapt
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-freebsd/attachments/20130402/13216bca/attachment-0001.sig>