On Fri, Oct 26, 2012 at 10:02:00PM +0100, Chris Rees wrote:
> On 26 Oct 2012 21:51, "Simon J. Gerraty" <s...@juniper.net> wrote:
> >
> >
> > On Fri, 26 Oct 2012 21:00:26 +0100, Chris Rees writes:
> > >:L -- seems that bmake's use for this is kinda pointless; returning the
> > >name of the variable; we could swap that usage over directly.
> >
> > Acutally it is very useful.
> > The debugging facilities in dirdeps.mk rely on it.
> > The junos build uses it in many other places too.
> >
> >
> > >:U -- with bmake has non-optional arguments, so for example:
> > >
> > >${VAR:U} - pmake behaviour
> > >
> > >${VAR:Uval} - make behaviour.
> > >
> > >Would that be acceptable? I can get a patch in if that's popular.
> >
> > No, please don't do that.
> > I'm trying to reduce the divergence b/w freebsd and netbsd.
>
> In that case we have a switch time on the order of years, not weeks; 8.3 is
> supported until May '14, and unless we get a :tl etc MFC into 8, even
> longer. All this time the ports tree must work with pmake.:tl/:tu has already been MFCed to 8 iirc. > > I don't want to discourage you or belittle your excellent work here, but > Marcel made me very nervous with his comment on the process being "a few > weeks". > > Chris
pgpnZ5uCglcDf.pgp
Description: PGP signature
