From owner-freebsd-arch@FreeBSD.ORG Thu Apr 17 20:29:39 2014 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 31185817 for ; Thu, 17 Apr 2014 20:29:39 +0000 (UTC) Received: from mail-pa0-f43.google.com (mail-pa0-f43.google.com [209.85.220.43]) (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 F05721FDB for ; Thu, 17 Apr 2014 20:29:38 +0000 (UTC) Received: by mail-pa0-f43.google.com with SMTP id bj1so746419pad.30 for ; Thu, 17 Apr 2014 13:29:32 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=VWA65BqCNHDwKNuzoNCCDQ8v/2QKxeYA1ilLEXug7i8=; b=cW5eK7nodJX6QeF+UXp+otiykkRcAey4RbNJpiKUCxJEu/SN4L7KaeV+6cygtO1dE8 e+AzYPunfo4+CTliFNBpsbwOri64NFTqL9wXj6Kmi5EU5rDuMCVbC9Oxo5cu4bmqYXC4 aDJbitF4m+JYcyswmPgECxAwCzmBj3imDMOEjYesd4ri1B3psUBIxhJSFA/vyxRsK8bt R8eJ6YgK770XFTSvfxEBPdW0geIf3RFQ3mmcQp9acJvaNyHTtpOYZ2AzPqcpKdEVK2ra 9uIR6C4N34azVu4+Z1aySzCm1xD6ti5N6F7j4kb6Rvwma3L419pZdTGimtfDwgikBMsC wIQg== X-Gm-Message-State: ALoCoQnSlZEXLu5Z0kaHblw/gewOOlj0vqIgnPfVakat3FQE6sVYnkrTzMtZ2Lq2S062yn2O9+W+ X-Received: by 10.68.143.231 with SMTP id sh7mr17963252pbb.7.1397766572259; Thu, 17 Apr 2014 13:29:32 -0700 (PDT) Received: from lgmac-ckapadia.corp.netflix.com (dc1-prod.netflix.com. [69.53.236.251]) by mx.google.com with ESMTPSA id yo9sm131082154pab.16.2014.04.17.13.29.30 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 17 Apr 2014 13:29:31 -0700 (PDT) Sender: Warner Losh Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) Subject: Re: make WITH[OUT]_* more useful? From: Warner Losh In-Reply-To: <20140417181159.0EFEA5809E@chaos.jnpr.net> Date: Thu, 17 Apr 2014 14:29:28 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <7C527DA8-ABC0-4D6A-AACB-64D89246B569@bsdimp.com> References: <20140401051327.F20F958097@chaos.jnpr.net> <20140401064316.GQ99393@ivaldir.etoilebsd.net> <766EFF76-7B41-423F-B447-DBA25BD14470@bsdimp.com> <20140401162912.7A9D058097@chaos.jnpr.net> <20140401195249.8752258097@chaos.jnpr.net> <2349B38E-F6F2-4911-92F2-3D62FCBD73DA@bsdimp.com> <20140402212328.7CE8958097@chaos.jnpr.net> <5D9BD168-D7E5-477E-AEA3-47B24445C89F@bsdimp.com> <20140410034645.C058658097@chaos.jnpr.net> <20140417063437.3BBF85809E@chaos.jnpr.net> <06CC1B46-2BF2-439C-8F97-16EA8DD7805C@bsdimp.com> <20140417181159.0EFEA5809E@chaos.jnpr.net> To: "Simon J. Gerraty" X-Mailer: Apple Mail (2.1874) Cc: Baptiste Daroussin , freebsd-arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Apr 2014 20:29:39 -0000 On Apr 17, 2014, at 12:11 PM, Simon J. Gerraty wrote: >=20 > On Thu, 17 Apr 2014 10:30:58 -0600, Warner Losh writes: >> This was step one: separate out the options processing from the =3D >> bsd.own.mk stuff. >> Having a few lines that are generic would be nice to include. I=3D92d = like =3D >> to go ahead and >> commit step 1, even if we refine things a bit later to keep the = change =3D >> sets manageable >> and under control=3D85 Is that reasonable? It will help other areas = and we =3D >> don=3D92t need to >> do much more than settle on filenames. :) >=20 > Sure. Naming stuff is hard, and warrants early attention. > On that front it occurred to me that (since it sets MK_*) > bsd.mkopts.mk might be a good name for the pure mechanism makefile. > So in the 3 level setup I mentioned you'd have: > bsd.own.mk -> bsd.srcopts.mk -> bsd.mkopts.mk Since we=92re planning a src.opts.mk at some point (to control /usr/src = builds), the bsd.srcopts.mk name seems to have a short shelf life. Maybe just = bsd.opts.mk? > If that sounds ok, I think we can proceed to next step. I=92d like to do the above tweak. There=92s on conflict with ports and = the name seems better. >>> Sorry, which file are you talking about?=3D20 >>=20 >> My bsd.srcopts.mk was what I was talking about here needing to be = added =3D >> to share/mk/Makefile. >=20 > Ah right. This is why I think separating the mechanism is good. > The mechanism should definitely be installed - because it is very = handy > (assuming some of the restrictions are removed). >=20 > The /usr/src "policy" is another matter (possibly bikeshed material = ;-) Yea, I think both of the above files, regardless of name, should be = installed. They just allow things to be configured, without providing a place to = configure them (well, without a place that=92s different than today=92s policy of = /etc/src.conf unless overridden). >>> FWIW I think all bsd.*.mk should get installed. >>> but I think it perfectly reasonable to declare that anything = matching =3D >> the >>> pattern local.* or src.* doesn't get installed. >>> Hopefully that shouldn't surprise anyone either. >>=20 >> IF we can achieve that separation, then great. >=20 > Yep. I=92ll start down that path once we have the above stuff done. >>> To restate that slightly differently, you can think of these things = as =3D >> a >>> hierarchy: >>> =3D20 >>> bsd.* mechanism for building stuff (not just /usr/src) >>> src.* stuff just for building /usr/src >>> local.* local tweaks to all the above >>=20 >> Yes, as long as the MK_FOO variables that are really src building = stuff =3D >> don=3D92t >> infect the bsd.foo.mk files, this could work out.=20 >=20 > Exactly. =20 >=20 > MK_* which are meaningful to bsd.*.mk need an option list in > bsd.*.mk - bsd.own.mk being perhaps a natural location? Yes. > For MK_* which are only actioned in makefiles like *bin/Makefile > they can be configured via a src.* file since they do not need to be > installed. I think so, yes. > By providing guidance and "obvious" places to list the two classes of > knobs we can limit the infection risk. Yea=85 There may be some contamination in user Makefiles today, but that should be minimal and will be easy to eradicate. >> Would we do a wholesale change of bsd.foo.mk to src.foo.mk for all = the =3D >> Makefiles >=20 > I'm not sure that would be necessary. > Having to support lots of active branches makes me leery of gratuitous > changes ;-) Yea. I=92d hoped you=92d say that. We build individual = programs/libraries with the bsd.*.mk files only, in general, although there may be some exceptions that are = carefully called out and those exceptions would only be to the extent of including the = src.opts.mk files. > If we had sys.mk do >=20 > .-include "src.sys.mk" > .-include "local.sys.mk" >=20 > that would be sufficient to enable all sorts of cool stuff. In non-posix mode, sure. This would be the natural place for the MK option setting. While it is early, it isn=92t too bad. It works great for buildworld scenarios, since we have a well-defined location for src.sys.mk. It works less well for the individual src Makefiles that might need to access variables set in src.sys.mk, which becomes unfindable w/o extra args on the command line, or requires knowledge of where the Makefile lives in the tree to reach over and snag it. > Similarly, bsd.init.mk doing >=20 > .-include "src.init.mk" > .-include "local.init.mk" >=20 > would allow for customization of things to be done after Makefile has > been read.=20 What would go there? Or would they be empty place holders? > The above would be sufficient to allow src.* to influence bin/Makefile > and lib/Makefile etc without the need to touch them. I both like and dislike that notion :) I more like than dislike it for = the bin/Makefile case (my only objection being it=20 > Other customization hooks would be cool too, bsd.sys.mk is a somewhat > unfortunate name, but it would be handy to have another point for > including {src,local}.*.mk at the end of the normal lib,prog,* mk = files. Also missing is a defined place for users to define WITH/WITHOUT_FOO. > Note that even though we don't install src.*.mk or local.*.mk, those > hook points are still very useful to anyone building their own stuff > with bsd.*.mk, since now they can customize their own builds without = the > need to hack bsd.*.mk=20 True, but it looks like it may make in-tree use in the non-build-world = case more complicated. There may be some resistance to that. Warner