From owner-svn-src-head@freebsd.org Tue Feb 27 16:47:40 2018 Return-Path: Delivered-To: svn-src-head@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D572EF3636F; Tue, 27 Feb 2018 16:47:39 +0000 (UTC) (envelope-from byond.lenox@gmail.com) Received: from mail-lf0-f41.google.com (mail-lf0-f41.google.com [209.85.215.41]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 51C5182617; Tue, 27 Feb 2018 16:47:39 +0000 (UTC) (envelope-from byond.lenox@gmail.com) Received: by mail-lf0-f41.google.com with SMTP id g72so9073643lfg.3; Tue, 27 Feb 2018 08:47:39 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=8WstpuPVOeg7L8nSyKA2UgqhdQigpfg5bhuVi2SWy/4=; b=K14RMH4KFexVxpitIBNkka3GBKL0No3PtVVTV73Qz4iVJL9hsiK7J/mQLRr6cKrnKu lVRuM5EE5ONzK9CxiufvjbUAeDuWXNfnqQy62f9VjumNQIOi28Qv3yCMmOTERVQad9Gn anhfTLhV6caYs2Xo2kOXnFTUHpLtIz7ro5XhXvV+mO3ZHZVKlFF/EerraLcUDe3/1e26 wzawnXtx9rhWzRATDmEwHQVtAt8tDR3fnCBjW+MH0N2HDhFsnUX7vAoi1MaTEvDOC7Fg CDU09hsHPGAHlyoujcbQarZxHgPFPvnY1bzygekd4o34SvsEg/F+Ktu7YmrS7S10Lqu0 xyRQ== X-Gm-Message-State: APf1xPBIrqok0nZkrxC9C4iFmNxyedRXe6n/a7riFfgeU/HHpA1Rpvnq ak1nl6w9VMbuutLBU5jIvySdXI09 X-Google-Smtp-Source: AH8x226H9YksOlqSUhfzh3wFWgbS0+pZQskAla0xWr5SyDkXqXdN60AUJAxKekcVLVYQopuzI6KB7Q== X-Received: by 10.46.27.211 with SMTP id c80mr11216605ljf.46.1519750051521; Tue, 27 Feb 2018 08:47:31 -0800 (PST) Received: from mail-lf0-f46.google.com (mail-lf0-f46.google.com. [209.85.215.46]) by smtp.gmail.com with ESMTPSA id b7sm2641499ljf.18.2018.02.27.08.47.31 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 27 Feb 2018 08:47:31 -0800 (PST) Received: by mail-lf0-f46.google.com with SMTP id g72so9073576lfg.3; Tue, 27 Feb 2018 08:47:31 -0800 (PST) X-Received: by 10.46.87.72 with SMTP id r8mr11103562ljd.93.1519750051137; Tue, 27 Feb 2018 08:47:31 -0800 (PST) MIME-Version: 1.0 Received: by 10.46.54.1 with HTTP; Tue, 27 Feb 2018 08:47:10 -0800 (PST) In-Reply-To: References: <201802260316.w1Q3G4vc022314@repo.freebsd.org> From: Kyle Evans Date: Tue, 27 Feb 2018 10:47:10 -0600 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: svn commit: r330004 - in head/stand: . arm efi forth i386 mips powerpc sparc64 To: Warner Losh Cc: Warner Losh , src-committers , svn-src-all@freebsd.org, svn-src-head@freebsd.org Content-Type: text/plain; charset="UTF-8" X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Feb 2018 16:47:40 -0000 On Tue, Feb 27, 2018 at 10:36 AM, Warner Losh wrote: > > > On Tue, Feb 27, 2018 at 8:33 AM, Kyle Evans wrote: >> >> n Tue, Feb 27, 2018 at 9:28 AM, Kyle Evans wrote: >> > On Sun, Feb 25, 2018 at 9:16 PM, Warner Losh 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. 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. > Lemme toss together a patch. > Excellent. =) > Warner