From owner-freebsd-arch@FreeBSD.ORG Fri Apr 18 02:57:35 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 C9DBB6F8 for ; Fri, 18 Apr 2014 02:57:35 +0000 (UTC) Received: from mail-pa0-f44.google.com (mail-pa0-f44.google.com [209.85.220.44]) (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 936F912A3 for ; Fri, 18 Apr 2014 02:57:35 +0000 (UTC) Received: by mail-pa0-f44.google.com with SMTP id bj1so1024028pad.31 for ; Thu, 17 Apr 2014 19:57:34 -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=60N7mEFAojRh4wTpk2cjBxmas+TDVeMALr4X/9/cJhs=; b=Zf5h4vU5KfQ37+rGFxDeEnfrspCNr1KHlz91QrWcFvDLMzWWvSkkknvGebka10C9PU uO1bUBuY8eRHKtYJ3p7btNvKJykbTOWEIpkMozhSD1+ZegWw9uqKETEyh5qyg438qs9e JjsIy50SYpcMgUsJqxv/mNP0EpXBGxtdfNiMYE7gxa2Yx+JXWdn+CAIY1OG9vSUU4bB3 d/WOogo+ka5ljNd4YJV8H0ojZKCXA0NOgOrZ1WVf5vPc9D1UYgZaQopixJJOoWjvcp7j YGOJbhKPDi8Q/3IayeKYlYAuj7nNJTW5ksIJ6r58GrcK8evf/LcgXh8MlVZTr8XnGICk Er4w== X-Gm-Message-State: ALoCoQnid6qndENBaDqArn4Lc8KX4gWZWwefle0/eyFefbQmk/bwDulMH/qnkIVKsq+w1H60dvnC X-Received: by 10.66.124.137 with SMTP id mi9mr19412128pab.111.1397789854457; Thu, 17 Apr 2014 19:57:34 -0700 (PDT) Received: from lgmac-ckapadia.corp.netflix.com (dc1-prod.netflix.com. [69.53.236.251]) by mx.google.com with ESMTPSA id ek2sm56628046pbd.30.2014.04.17.19.57.33 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 17 Apr 2014 19:57:33 -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: <20140417220633.242585809F@chaos.jnpr.net> Date: Thu, 17 Apr 2014 20:57:31 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <18D76DD4-AA14-46CB-8D41-6176D08FA56F@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> <7C527DA8-ABC0-4D6A-AACB-64D89246B569@bsdimp.com> <20140417220633.242585809F@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: Fri, 18 Apr 2014 02:57:35 -0000 On Apr 17, 2014, at 4:06 PM, Simon J. Gerraty wrote: >=20 > On Thu, 17 Apr 2014 14:29:28 -0600, Warner Losh writes: >>> bsd.own.mk -> bsd.srcopts.mk -> bsd.mkopts.mk >>=20 >> Since we=3D92re planning a src.opts.mk at some point (to control = /usr/src bui=3D >> lds), >> the bsd.srcopts.mk name seems to have a short shelf life. Maybe just = bsd.op=3D >> ts.mk? >=20 > Sure bsd.opts.mk sounds fine. Done. >>> .-include "src.sys.mk" >>> .-include "local.sys.mk" >>> =3D >>=20 >>> that would be sufficient to enable all sorts of cool stuff. >>=20 >> In non-posix mode, sure. This would be the natural place for >> the MK option setting. While it is early, it isn=3D92t 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. >=20 > I've avoided that issue for ages by using a wrapper script to = condition > the env for the tree I'm working in, junos freebsd, netbsd etc. > If all your trees have a share/mk, that you want to use you can just=20= > export MAKESYSPATH=3D".../share/mk" > and bmake will DTRT. Can that be set in a Makefile? >>> Similarly, bsd.init.mk doing >>> =3D >>=20 >>> .-include "src.init.mk" >>> .-include "local.init.mk" >>> =3D >>=20 >>> would allow for customization of things to be done after Makefile = has >>> been read. =3D >>=20 >> What would go there? Or would they be empty place holders? >=20 > It depends. Some things need to be done after Makefile has been read > (rather than before) - eg any variable ref on rhs of dependency rule > needs to have a value at that time. >=20 > Let's say I wanted to be able to build head in meta mode (rather than > keep syncing to projects/bmake). > If there were suitable local.*.mk hook points I could do that without > affecting anyone else, until such time as I can convince others that = its > a brilliant idea ;-) >=20 > Even if FreeBSD.org decide they want to build /usr/src in > meta mode, that doesn't mean that every user of FreeBSD wants all = their > own projects to build that way. Some of the glue I had in local.*.mk > could move to src.*.mk so that /usr/src could leverage it without > impacting every user of bsd.*.mk >=20 > That's just one example of course. OK. I=92m sold. >> Also missing is a defined place for users to define WITH/WITHOUT_FOO. >=20 > You can still support {src,local,make}.conf OK. Will keep it around. >> True, but it looks like it may make in-tree use in the = non-build-world case=3D >> more complicated. There may be some resistance to that. >=20 > I'm not sure it would impact one way or the other. > It all boils down to whether /usr/share/mk, -m * or $MAKESYSPATH > are used. >=20 > I would figure anyone inclined to go adding local.*.mk to their tree, > would be able to cope with setting MAKESYSPATH or whatever else it = takes > to do what they want. Yea, I agree for local.*.mk, but the case is less clear for src.*.mk = which is now required for the build=85 I should do a census on the number of = files this affects. I=92ll post patches as soon as I finish make universe. Warner