Date: Thu, 23 Jan 2014 13:30:12 -0800 From: Garrett Cooper <yaneurabeya@gmail.com> To: "Simon J. Gerraty" <sjg@juniper.net> Cc: "freebsd-testing@freebsd.org" <freebsd-testing@freebsd.org>, brooks@freebsd.org Subject: Re: Makefile.inc1.patch Message-ID: <EBDCAEEC-9485-4EA5-AA60-943EA70A3171@gmail.com> In-Reply-To: <20140123210308.0E1D65807E@chaos.jnpr.net> References: <B4D2A908-715F-484F-8028-A1F38884AF3F@gmail.com> <CAOtMX2jQ24JCR2Ct8YKob4MKcHWMhVVv5XG-1usoPWqEOA2OQg@mail.gmail.com> <4A3E3984-73D3-4441-97A7-D58679EFF978@gmail.com> <9775878D-91AB-4BE4-ADFA-32D8DB582AA6@gmail.com> <20140123210308.0E1D65807E@chaos.jnpr.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Jan 23, 2014, at 1:03 PM, Simon J. Gerraty <sjg@juniper.net> wrote:
> [+brooks]
>=20
> On Thu, 23 Jan 2014 12:53:31 -0800, Garrett Cooper writes:
>> Here=3D92s the working patch. The difference between this one =
and =3D
>> the prior version is that you have to explicitly override -DNO_TESTS =
=3D
>> when building lib/atf* (Simon: do you have any comments?):
>=20
> Not crazy about frobbing ${MAKE}
Neither am I, but .export is a bmake only feature. I=92m still using =
fmake :(.
>> -.if ${MK_TESTS} !=3D3D "no"
>> +.if defined(WITH_ATF) || ${MK_TESTS} !=3D3D "no"
>> +# Make sure WITH_ATF overrules -DNO_TESTS
>> +.if !defined(WITH_ATF)
>> +MAKE+=3D3D -DWITH_ATF
>> +.endif
>=20
> Would it make sense to have ATF or TESTS depend on the other?
This functionality was removed several months ago.. otherwise I would =
totally agree :/.
> As is that can't be done, since one cannot always safely include
> bsd.own.mk from the tree.
>=20
> I'd really like to see the WITH[OUT]_ processing separated to its own
> makefile (I use options.mk) so that it can always be safely used - =
even
> with an option list specific to a given makefile.
Yeah, I would too [in an ideal world], but a lot of stuff is dependent =
per-TARGET/TARGET_ARCH and compiler, so things get super complicated =
really quickly in that regard.
>=20
> The semantics in bsd.own.mk are quite broken and result in a lot of =
complex
> dancing to keep things working.
In this case though, this is complex dancing due to how the different =
stages stack upon one another in the build process and the fact that =
meta make isn=92t here (yet), so things have to be built in the right =
order. This method is one that I=92ve been using for quite some time =
without any side effects on multiple machines...
>>=20
>> I unrolled most of the local changes to Makefile.inc1 on my =3D
>> github fork so it=3D92ll be easier to spot if you diff it against my =
tree.
Thanks,
-Garrett=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?EBDCAEEC-9485-4EA5-AA60-943EA70A3171>