On Monday 01 October 2007, Donnie Berkholz wrote: > On 07:46 Mon 01 Oct , Ali Polatel (hawking) wrote: > > 1.1 sys-auth/pam_chroot/pam_chroot-0.9.2.ebuild > > > > file : > > http://sources.gentoo.org/viewcvs.py/gentoo-x86/sys-auth/pam_chroot/pam_c > >hroot-0.9.2.ebuild?rev=1.1&view=markup plain: > > http://sources.gentoo.org/viewcvs.py/gentoo-x86/sys-auth/pam_chroot/pam_c > >hroot-0.9.2.ebuild?rev=1.1&content-type=text/plain > > > > LDFLAGS="$(raw-ldflags)" emake \ > > CC="$(tc-getCC)" LD="$(tc-getLD)" || die "emake failed" > > This reads really strangely to me. It's passing variables on both sides > of emake. Generally one would just pick a side (afterwards) and add > everything there.
while i cant speak for this case, make provides the ability to check for the location of where a variable is defined and change behavior based on it ... here, make would say LDFLAGS is in the environment while CC and LD were defined on the command line ... see the $(origin) function also, make changes behavior for setting of variables based on the origin of definition ... the "=" and "+=" operators get ignored when the variable is on the command line, but work when in the environment ... then again, makefiles that get screwy based on this i think are broken in the first place and should get fixed ... -mike
signature.asc
Description: This is a digitally signed message part.
