svn commit: r392209 - in head/devel: . p5-Minilla

[Baptiste Daroussin]

On Thu, Jul 16, 2015 at 02:52:01PM +0000, Alexey Dokuchaev wrote:
> On Thu, Jul 16, 2015 at 11:20:53AM +0200, Baptiste Daroussin wrote:
> > On Thu, Jul 16, 2015 at 11:10:22AM +0200, Baptiste Daroussin wrote:
> > > On Thu, Jul 16, 2015 at 01:43:06AM +0000, Alexey Dokuchaev wrote:
> > > > Can you clarify on what is wrong with := ?  I've added IMHO quite clear
> > > > and elaborate explanation in the PH on the matter, and I don't see the
> > > > merit of using MY_DEPENDS at all: it's ugly, it's hard to read, it
> > > > pollutes namespace for no sound reason.
> > > 
> > > := enforce the expansion to happen right away
> > > 
> > > Let's say you have:
> > > 
> > > RUN_DEPENDS=	${BLOODYSCRIPTLANGUAGEPREFIX}bal>0:${PORTSDIR}/somewhere/bla
> > > BULID_DEPENDS:=	${RUN_DEPENDS}
> > > 
> > > .include <bsd.port.mk>
> > > 
> > > BULID_DEPENDS will magically have ${BLOODYSCRIPTLANGUAGEPREFIX} expanded
> > > to "" because it is not yet defined at the moment the expansion is
> > > requested.
> > 
> > Well my example is bad here because undefined variable will be expanded
> > later, but I think you got the point about inconsistency of the expansion
> > with := and look at the svn history I have fixed a couple of weird issues
> > we hard in the ports tree due do weirdness of how := do the expansion.
> > 
> > I prefer a sane (yet ugly) constuction that consistently works the same
> > over the portstree than I constuction which can bite contributors and get
> > quite complex to debug.
> 
> I see your point.  I'm not saying that := is *always* a better way; even
> though I must say debugging Makefiles is pretty easy with -V FOO and @echo
> in recipes.  What I'm not happy with is blunt ":= is wrong, don't ever use
> it!" statement: it does come handy often in many cases and checking if it
> does the right thing is easy once you compare "make -V RUN_DEPENDS | md5"
> vs. "make -V BULID_DEPENDS | md5" (in addition to visual examination).

That is imho a too pedantic approach, pragmatism should lead and pragmatism is
people often misunderstand it, and most people do not understand make(1)
internals (I won't blame them for that, I would prefer not knowing it in the
first place). By people I mean both maintainers and committers if you bring to
the battle the back we do support 2 differents make with slightly different
behaviours in some part it becomes even more complicated.

We should promote safe syntaxes by handbook or by our own practive because it
will be used as example by others. that will save us from hours having to clean
the ports tree where things can easily break as a side effect of changes in
other parts of the framework.

Best regards,
Bapt
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 181 bytes
Desc: not available
URL: <http://lists.freebsd.org/pipermail/svn-ports-all/attachments/20150716/fe4c513e/attachment.bin>