Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 16 Jul 2015 16:59:21 +0200
From:      Baptiste Daroussin <bapt@FreeBSD.org>
To:        Alexey Dokuchaev <danfe@FreeBSD.org>
Cc:        Mathieu Arnold <mat@FreeBSD.org>, Dmitry Marakasov <amdmi3@FreeBSD.org>, ports-committers@freebsd.org, svn-ports-all@freebsd.org, svn-ports-head@freebsd.org
Subject:   Re: svn commit: r392209 - in head/devel: . p5-Minilla
Message-ID:  <20150716145920.GY37597@ivaldir.etoilebsd.net>
In-Reply-To: <20150716145201.GA13745@FreeBSD.org>
References:  <201507152017.t6FKHElA056017@svnmir.geo.freebsd.org> <F55E1B42FC419AF2D5795884@atuin.in.mat.cc> <20150716014306.GA68880@FreeBSD.org> <20150716091021.GW37597@ivaldir.etoilebsd.net> <20150716092053.GX37597@ivaldir.etoilebsd.net> <20150716145201.GA13745@FreeBSD.org>

next in thread | previous in thread | raw e-mail | index | archive | help

--mFM6r0jQWo48NPCK
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

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 :=3D ?  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.
> > >=20
> > > :=3D enforce the expansion to happen right away
> > >=20
> > > Let's say you have:
> > >=20
> > > RUN_DEPENDS=3D	${BLOODYSCRIPTLANGUAGEPREFIX}bal>0:${PORTSDIR}/somewhe=
re/bla
> > > BULID_DEPENDS:=3D	${RUN_DEPENDS}
> > >=20
> > > .include <bsd.port.mk>
> > >=20
> > > BULID_DEPENDS will magically have ${BLOODYSCRIPTLANGUAGEPREFIX} expan=
ded
> > > to "" because it is not yet defined at the moment the expansion is
> > > requested.
> >=20
> > Well my example is bad here because undefined variable will be expanded
> > later, but I think you got the point about inconsistency of the expansi=
on
> > with :=3D and look at the svn history I have fixed a couple of weird is=
sues
> > we hard in the ports tree due do weirdness of how :=3D do the expansion.
> >=20
> > I prefer a sane (yet ugly) constuction that consistently works the same
> > over the portstree than I constuction which can bite contributors and g=
et
> > quite complex to debug.
>=20
> I see your point.  I'm not saying that :=3D 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 ":=3D 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 c=
lean
the ports tree where things can easily break as a side effect of changes in
other parts of the framework.

Best regards,
Bapt

--mFM6r0jQWo48NPCK
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iEYEARECAAYFAlWnxsgACgkQ8kTtMUmk6EytOACfZe0MAhKRGeFOzE/KNowPuWsD
L+MAn1R5smTHeZTAHJeq7f0iaOPM7MJt
=piSp
-----END PGP SIGNATURE-----

--mFM6r0jQWo48NPCK--



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