Date: Fri, 26 Oct 2012 21:00:26 +0100 From: Chris Rees <utisoft@gmail.com> To: freebsd-hackers@freebsd.org, Chris Rees <crees@freebsd.org>, freebsd-arch@freebsd.org, Marcel Moolenaar <marcel@xcllnt.net>, "Simon J. Gerraty" <sjg@juniper.net>, "David E. O'Brien" <obrien@freebsd.org>, Baptiste Daroussin <bapt@freebsd.org>, Garrett Cooper <yanegomi@gmail.com> Subject: Re: [CFT/RFC]: refactor bsd.prog.mk to understand multiple programs instead of a singular program Message-ID: <CADLo83-d0tDN8k5Lv9c5=6vQawVHSHZENfTpKzxe61OYqqxSeA@mail.gmail.com> In-Reply-To: <CADLo838vSnYm3LMr_6maQipAYtBTX%2BCCyEhC053cj_amgNJH=g@mail.gmail.com> References: <201210020750.23358.jhb@freebsd.org> <CAGH67wTM1VDrpu7rS=VE1G_kVEOHhS4-OCy5FX_6eDGmiNTA8A@mail.gmail.com> <201210021037.27762.jhb@freebsd.org> <CAGH67wQffjVHqFw_eN=mfeg-Ac2Z6XBT5Hv72ev0kjjx7YH7SA@mail.gmail.com> <127FA63D-8EEE-4616-AE1E-C39469DDCC6A@xcllnt.net> <20121025211522.GA32636@dragon.NUXI.org> <3F52B7C9-A7B7-4E0E-87D0-1E67FE5D0BA7@xcllnt.net> <CAGH67wRw_n2_KwVz=DZkMpeJ4t8mMf965nxehHsDV-mzTnn5cA@mail.gmail.com> <CADLo839EUTF9bP8VD3L1_boY8i-w8B87yHGRR7Zx6wONFnSnEQ@mail.gmail.com> <20121025221244.GG3808@ithaqua.etoilebsd.net> <20121026181152.GC44331@dragon.NUXI.org> <CADLo838vSnYm3LMr_6maQipAYtBTX%2BCCyEhC053cj_amgNJH=g@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 26 Oct 2012 20:15, "Chris Rees" <utisoft@gmail.com> wrote:
>
>
> On 26 Oct 2012 19:12, "David O'Brien" <obrien@freebsd.org> wrote:
> >
> > On Fri, Oct 26, 2012 at 12:12:44AM +0200, Baptiste Daroussin wrote:
> > > Do be able to get the ports tree working with bmake asap, I also asked
> > > him to MFC it to 9.1, from latest reply he got positive answer from
re@
> > > about this, but was waiting for something I don't remember.
> >
> > :tu/:tl is in releng/9.1, so it will also be in 9.1-RELEASE.
>
> Then we only have two supported stable branches you propose to break...
>
OK, how about this:
:L -- seems that bmake's use for this is kinda pointless; returning the
name of the variable; we could swap that usage over directly.
: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.
Chris
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CADLo83-d0tDN8k5Lv9c5=6vQawVHSHZENfTpKzxe61OYqqxSeA>