Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 22 Mar 2004 14:48:13 +0100 (CET)
From:      Harti Brandt <brandt@fokus.fraunhofer.de>
To:        ports@freebsd.org
Subject:   ports infrastructure changes for standards/57295
Message-ID:  <20040322143029.A55144@beagle.fokus.fraunhofer.de>

next in thread | raw e-mail | index | archive | help
  This message is in MIME format.  The first part should be readable text,
  while the remaining parts are likely unreadable without MIME-aware tools.
  Send mail to mime@docserver.cac.washington.edu for more info.

--0-206516692-1079963293=:55144
Content-Type: TEXT/PLAIN; charset=US-ASCII


Hi all,

a test build on bento with the patch from the above PR has shown that
a lot of port builds are broken by this patch. There are mainly three
sources of breakage two of which are infrastucture related. For those
I need the help of the ports gurus to come up with appropriate changes.

The first and probably most easiest to fix problem is the breakage of
imake-4. This is caused by the port's makefile overriding the top-level's
Makefile SUBDIR variable by specifying a new value for it on make's
command line. With a POSIX compliant make this doesn't work, because
command line assignments get absolute priority over makefile assignments
and are passed down to all sub-makes. So make SUBDIR='foo bar' overwrites
SUBDIR not only at the top-level, but also on all sub-makes, which wont
work of course. I have sent appripriate patches to imakes maintainers, so
this is fixed. There may be other ports suffering from this problem.

The next problem is examplified by dns/bind8. It contains a patch to add
'SH=${SH}' to a file that is then used to get command line parameters to
the makes that will build the port. Again with a POSIX complient make
this assignment gets evaluated at make startup time and leads to a
recursive variable assignment error. The problem here is that in order to
fix this we might need to apply different patches to the port for
different make version: with the old make we need the patch that adds the
SH line, with the new one we need a patch without this line. So my
question is: is this doable? Or is there another workaround for this
problem?

The third problem lies in the bsd.ports.mk. Version 1.315 added a speedup
by passing certain variables to sub-makes via command line assignments
(look for __softMAKEFLAGS). This wont work with the patched make, because
these variables are not-overrideable by submakes and this breaks any build
of dependent ports. I think this problem causes most breakage. I was able
to circumvent the problem by specifying NOPRECIOUSMAKEVARS=yes to make,
but don't know whether this is the correct thing to do. And, to be honest,
I don't fully understand what this __softMAKEFLAGS thing does. So could
please someone help me with this?

I have attached the patch to make from the above PR.

Regards,
harti
--0-206516692-1079963293=:55144
Content-Type: TEXT/PLAIN; charset=US-ASCII; name="make.diff"
Content-Transfer-Encoding: BASE64
Content-ID: <20040322144813.U55144@beagle.fokus.fraunhofer.de>
Content-Description: 
Content-Disposition: attachment; filename="make.diff"

ZGlmZiAtdXIgL3Vzci9zcmMvdXNyLmJpbi9tYWtlL21haW4uYyAuL21haW4u
Yw0KLS0tIC91c3Ivc3JjL3Vzci5iaW4vbWFrZS9tYWluLmMJU2F0IERlYyAx
MyAxNjoyNjoyNyAyMDAzDQorKysgLi9tYWluLmMJU2F0IE1hciAyMCAxODo0
NjowNSAyMDA0DQpAQCAtNjM2LDYgKzYzNiwxMCBAQA0KIA0KIAlNYWluUGFy
c2VBcmdzKGFyZ2MsIGFyZ3YpOw0KIA0KKyNpZmRlZiBQT1NJWA0KKwlWYXJf
QWRkQ21kbGluZShNQUtFRkxBR1MpOw0KKyNlbmRpZg0KKw0KIAkvKg0KIAkg
KiBGaW5kIHdoZXJlIHdlIGFyZS4uLg0KIAkgKiBBbGwgdGhpcyBjb2RlIGlz
IHNvIHRoYXQgd2Uga25vdyB3aGVyZSB3ZSBhcmUgd2hlbiB3ZSBzdGFydCB1
cA0KZGlmZiAtdXIgL3Vzci9zcmMvdXNyLmJpbi9tYWtlL25vbmludHMuaCAu
L25vbmludHMuaA0KLS0tIC91c3Ivc3JjL3Vzci5iaW4vbWFrZS9ub25pbnRz
LmgJVHVlIE1hciAxNiAxMjozNjoxMiAyMDA0DQorKysgLi9ub25pbnRzLmgJ
U2F0IE1hciAyMCAxODo0NjowNSAyMDA0DQpAQCAtMTM1LDYgKzEzNSw3IEBA
DQogdm9pZCBWYXJfQXBwZW5kKGNoYXIgKiwgY2hhciAqLCBHTm9kZSAqKTsN
CiBCb29sZWFuIFZhcl9FeGlzdHMoY2hhciAqLCBHTm9kZSAqKTsNCiBjaGFy
ICpWYXJfVmFsdWUoY2hhciAqLCBHTm9kZSAqLCBjaGFyICoqKTsNCit2b2lk
IFZhcl9BZGRDbWRMaW5lKGNoYXIgKik7DQogY2hhciAqVmFyX1BhcnNlKGNo
YXIgKiwgR05vZGUgKiwgQm9vbGVhbiwgaW50ICosIEJvb2xlYW4gKik7DQog
Y2hhciAqVmFyX1N1YnN0KGNoYXIgKiwgY2hhciAqLCBHTm9kZSAqLCBCb29s
ZWFuKTsNCiBjaGFyICpWYXJfR2V0VGFpbChjaGFyICopOw0KZGlmZiAtdXIg
L3Vzci9zcmMvdXNyLmJpbi9tYWtlL3Zhci5jIC4vdmFyLmMNCi0tLSAvdXNy
L3NyYy91c3IuYmluL21ha2UvdmFyLmMJTW9uIEphbiAxMiAxMTozNTo0NiAy
MDA0DQorKysgLi92YXIuYwlTYXQgTWFyIDIwIDE4OjQ2OjA1IDIwMDQNCkBA
IC04MzIsNiArODMyLDQyIEBADQogfQ0KIA0KIA0KKyNpZmRlZiBQT1NJWA0K
Kw0KKw0KKy8qIEluIFBPU0lYIG1vZGUsIHZhcmlhYmxlIGFzc2lnbm1lbnRz
IHBhc3NlZCBvbiB0aGUgY29tbWFuZCBsaW5lIGFyZQ0KKyAqIHByb3BhZ2F0
ZWQgdG8gc3ViIG1ha2VzIHRocm91Z2ggTUFLRUZMQUdTLg0KKyAqLw0KK3Zv
aWQNCitWYXJfQWRkQ21kbGluZShjaGFyICpuYW1lKQ0KK3sNCisgICAgY29u
c3QgVmFyICp2Ow0KKyAgICBMc3ROb2RlIGxuOw0KKyAgICB1bnNpZ25lZCBp
bnQgaTsNCisgICAgQnVmZmVyIGJ1ZjsNCisgICAgc3RhdGljIGNvbnN0IGNo
YXIgcXVvdGFibGVbXSA9ICIgXHRcblxcJ1wiIjsNCisgICAgY2hhciAqczsN
CisNCisgICAgYnVmID0gQnVmX0luaXQgKE1BS0VfQlNJWkUpOw0KKw0KKyAg
ICBmb3IgKGxuID0gTHN0X0ZpcnN0KFZBUl9DTUQtPmNvbnRleHQpOyBsbiAh
PSBOVUxMOw0KKwlsbiA9IExzdF9TdWNjKGxuKSkgew0KKwkgICAgLyogV2Ug
YXNzdW1lIHZhcmlhYmxlIG5hbWVzIGRvbid0IG5lZWQgcXVvdGluZyAqLw0K
KwkgICAgdiA9IChWYXIgKilMc3RfRGF0dW0obG4pOw0KKwkgICAgQnVmX0Fk
ZEJ5dGVzKGJ1Ziwgc3RybGVuKHYtPm5hbWUpLCB2LT5uYW1lKTsNCisJICAg
IEJ1Zl9BZGRCeXRlKGJ1ZiwgJz0nKTsNCisJICAgIGZvciAocyA9IEJ1Zl9H
ZXRBbGwodi0+dmFsLCAoaW50ICopTlVMTCk7ICpzICE9ICdcMCc7IHMrKykg
ew0KKwkJaWYgKHN0cmNocihxdW90YWJsZSwgKnMpKQ0KKwkJICAgIEJ1Zl9B
ZGRCeXRlKGJ1ZiwgJ1xcJyk7DQorCQlCdWZfQWRkQnl0ZShidWYsICpzKTsN
CisJICAgIH0NCisJICAgIEJ1Zl9BZGRCeXRlKGJ1ZiwgJyAnKTsNCisgICAg
fQ0KKyAgICBWYXJfQXBwZW5kKG5hbWUsIEJ1Zl9HZXRBbGwoYnVmLCAoaW50
ICopTlVMTCksIFZBUl9HTE9CQUwpOw0KKyAgICBCdWZfRGVzdHJveShidWYs
IDEpOw0KK30NCisjZW5kaWYNCisNCiAvKi0NCiAgKi0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tDQogICogVmFyX1BhcnNlIC0tDQo=

--0-206516692-1079963293=:55144--



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040322143029.A55144>