svn commit: r330004 - in head/stand: . arm efi forth i386 mips powerpc sparc64

[Warner Losh]

On Tue, Feb 27, 2018 at 9:47 AM, Kyle Evans <kevans at freebsd.org> wrote:

> On Tue, Feb 27, 2018 at 10:36 AM, Warner Losh <imp at bsdimp.com> wrote:
> >
> >
> > On Tue, Feb 27, 2018 at 8:33 AM, Kyle Evans <kevans at freebsd.org> wrote:
> >>
> >> n Tue, Feb 27, 2018 at 9:28 AM, Kyle Evans <kevans at freebsd.org> wrote:
> >> > On Sun, Feb 25, 2018 at 9:16 PM, Warner Losh <imp at freebsd.org> wrote:
> >> >> Author: imp
> >> >> Date: Mon Feb 26 03:16:04 2018
> >> >> New Revision: 330004
> >> >> URL: https://svnweb.freebsd.org/changeset/base/330004
> >> >>
> >> >> Log:
> >> >>   Add NO_OBJ to those directories that don't make anything.
> >> >>
> >> >>   For directories that don't many anything, add NO_OBJ=t just before
> we
> >> >>   include bsd.init.mk. This prevents them from creating an OBJ
> >> >>   directory. In addition, prevent defs.mk from creating the machine
> >> >>   related links in these cases. They aren't needed and break, at
> least
> >> >>   on stable, the read-only src tree build.
> >> >>
> >> >
> >> > Any objection to also removing efi from i386 SUBDIR? It seems silly
> >> > to be explicitly adding it when we know nothing here is applicable and
> >> > it's going to take some amount of work to get there.
> >>
> >> In fact, this block [1] feels wrong, too... why are we adding efi to
> >> SUBDIR for arch's that don't support it? I understand the GCC checks,
> >> but libefi, loader, and boot1 are the main bits of efi/, why are these
> >> stuck behind MACHINE_CPUARCH checks?
> >>
> >> [1]
> >> https://svnweb.freebsd.org/base/head/stand/efi/Makefile?view=markup#l17
> >
> >
> > I think that none of the arch tests in that file are anywhere near legit
> in
> > that file. More cargo-cult kludgery to eliminate in the build system.
> I'll
> > take care of that. If i386 builds, we should keep it, otherwise we
> > shouldn't. In fact, we should move all the EFI ifdef junk-o-matic crap
> from
> > Makefile.<arch> at the top level as well.
> >
>
> Right- the arch tests surrounding the FDT bits are pointless and only
> really stop us from building something we won't be using (since FDT is
> default yes regardless of arch, for some reason).
>
> It would be nice if we could build efi/fdt based on whether we'll be
> building an EFI loader w/ HAVE_FDT set rather than these arch tests,
> but I understand that that's not necessarily straightforward.


It all comes from a fundamental misunderstanding that there's three options
for every build option: default yes, default no, and broken....

Warner


> Lemme toss together a patch.
> >
>
> Excellent. =)
>
> > Warner
>