From owner-freebsd-arch@FreeBSD.ORG Thu Sep 25 01:22:37 2014 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B4C395D1; Thu, 25 Sep 2014 01:22:37 +0000 (UTC) Received: from mail-ie0-x22f.google.com (mail-ie0-x22f.google.com [IPv6:2607:f8b0:4001:c03::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 769F08D5; Thu, 25 Sep 2014 01:22:37 +0000 (UTC) Received: by mail-ie0-f175.google.com with SMTP id rl12so6246651iec.6 for ; Wed, 24 Sep 2014 18:22:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=su12T/qZOueRWE4QBlFUo3HcjH2vTjfb4dItg6ZDT30=; b=o+dPRfi8KSGjl9YehoBmrV9Utj/dbuoiQLBaRIMghXaoud31rpi9NnjIDIzBoD2VBR 0tAFtDv4QzMzIYWYBrdAQt4Uwc3jndykYqfgjVYLmcr7T7MLaop/eWrKSMV//6logeJE x1hw66HkT5UaTpWw3Ml4HWG8jPNky7cRk/su4FjR9ZbaZpss6tvL+dK6JytRUuFElqlv YQQJ04d5jc+v0YH+nYZbyt6VwLWXm42aC1zgscKqo1Aa97HieSEc26+kenmHQW+0t3bE uAiCg7A1P97ovnIfUfSHneVVzxT+j31+r/wJZ/jirGk4tFAmKPZd70gtm2G4v9Gm+0rU 4RRA== MIME-Version: 1.0 X-Received: by 10.50.57.110 with SMTP id h14mr627110igq.26.1411608156635; Wed, 24 Sep 2014 18:22:36 -0700 (PDT) Received: by 10.50.72.69 with HTTP; Wed, 24 Sep 2014 18:22:36 -0700 (PDT) In-Reply-To: <8D6B4CD4-D099-4BA9-9BE1-39FC4658A992@bsdimp.com> References: <11E49217-8154-47AC-8D39-68256017D3A8@gmail.com> <0A216B9F-3437-461E-A52A-032F6B86B5F2@bsdimp.com> <5421F165.7030304@wemm.org> <20140923231205.GA40545@hub.FreeBSD.org> <8CE07FF2-6D08-4270-8214-1C8493E56536@gmail.com> <8D6B4CD4-D099-4BA9-9BE1-39FC4658A992@bsdimp.com> Date: Wed, 24 Sep 2014 18:22:36 -0700 Message-ID: Subject: Re: [RFC] fully integrate etc/Makefile into bsd.prog.mk From: NGie Cooper To: Warner Losh Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Glen Barber , "freebsd-arch@FreeBSD.org Arch" X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Sep 2014 01:22:37 -0000 On Wed, Sep 24, 2014 at 9:07 AM, Warner Losh wrote: > > On Sep 23, 2014, at 5:20 PM, Garrett Cooper wrote= : > >> On Sep 23, 2014, at 16:12, Glen Barber wrote: >> >> ... >> >>> And the "other people's" is exactly why etc/Makefile should remain >>> untouched. Many companies build their own releases, and touching >>> something for the sake of touching something will inevitably break >>> something that has worked for a long time. >>> >>> In my opinion, etc/Makefile is not broken, so there is no reason to >>> "fix" it. You can consider my reply an objection to arbitrary changes >>> to etc/Makefile, in this case. >> >> Ok. I=E2=80=99ll rescind my proposal to cleanup/change the structu= re/method used for installing things in etc/Makefile, and instead focus on = testing and review of the removal of optional pieces from the install which= are always installed. >> Thank you for the input, > > That=E2=80=99s why I asked what the plan was. etc/Makefile is simply frau= ght with danger. My lack of a plan was probably what caused the FUD. I didn't have one yet because I was doing initial investigation to see whether or not what I was proposing was even plausible. Basically, the idea was to do the following: Goal: - All high level/documented targets (all, clean, distribute, distribution, install, etc) would remain untouched. No backwards compatibility would be broken when doing this work. Tasks: 1. Any "missing" Makefiles in subdirectories would be added/converted as needed to bsd.prog.mk in order to handle "make distribution" cleanly. 2. All lines like "cd ${.CURDIR}/some-dir; make install" executed under the distribution target would turn into something like this: # Only install these items with make distribution. .if make(distribution) SUBDIR+=3D some-dir .endif I would need to change ${.TARGET} to execute install like is currently being done today (with exception of sendmail -- which handles make distribution), unless I created a Makefile.inc in the directory which created the distribution target as needed. 3. Everything would be converted over to FILES/FILESDIR or SCRIPTS/SCRIPTSDIR in etc/Makefile that is installed from etc. 4. Everything that's not installed from /etc would be moved to their relevant subdir Makefile. 5. Targets that handle creating login.conf.db, etc would be moved to the end of the target, or be moved to a supporting target which would ensure that vendors/users would have the ability to customize ${DESTDIR}/etc before cap_mkdb, etc are run, eliminating the need for duplicated logic in scripts. Thanks, -Garrett