From owner-freebsd-arch@FreeBSD.ORG Thu Apr 17 16:31:02 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 70C228EF for ; Thu, 17 Apr 2014 16:31:02 +0000 (UTC) Received: from mail-pa0-f52.google.com (mail-pa0-f52.google.com [209.85.220.52]) (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 3C6DB14F7 for ; Thu, 17 Apr 2014 16:31:01 +0000 (UTC) Received: by mail-pa0-f52.google.com with SMTP id rd3so552429pab.11 for ; Thu, 17 Apr 2014 09:31:01 -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=ASz+Kg+OE0uN39J7w5ST4jJ7DzlmFMriSQ2eGqpEfkU=; b=UT339FFFlHW9WpQensabXNps+J4MyIzKGgx8NT0e0xmrGxDWVR1AKpYwsmv7dZdcEI njqkGex6Rj4jVhpkbQK38sULD2pas7CVUsizvfAq8ZvoUBVaO0sFM7Y474crZnO7vkZy 0cq9lbas/HrOD9r5HkcNgbRK1msNV+4S51wD6Lz0wl8o2c7YRN9OFIJBSYyDumFPpqSj GEMPv49P5/hdRwnVGJPQw2QCxDYQLx3ssNuAis50qA7cHxqDnI6sTdGEMrKVlFXRCRd+ R1z8KKthQYM8E0xzOLhbZoIItJetGLDEc4s3kWQN5W/vXxtjbDV6nM0ltuFy3DtuX/C5 qRag== X-Gm-Message-State: ALoCoQmsIClqetWmx9ETzzFX6RwFlp8cxaQVESrxscjfbSGE24aD5rivHaTfHNDBC52I3sLy+H4l X-Received: by 10.68.226.197 with SMTP id ru5mr16615273pbc.77.1397752260994; Thu, 17 Apr 2014 09:31:00 -0700 (PDT) Received: from lgmac-ckapadia.corp.netflix.com (dc1-prod.netflix.com. [69.53.236.251]) by mx.google.com with ESMTPSA id ff4sm128677125pad.24.2014.04.17.09.30.59 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 17 Apr 2014 09:31:00 -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: <20140417063437.3BBF85809E@chaos.jnpr.net> Date: Thu, 17 Apr 2014 10:30:58 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <06CC1B46-2BF2-439C-8F97-16EA8DD7805C@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> 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 16:31:02 -0000 On Apr 17, 2014, at 12:34 AM, Simon J. Gerraty wrote: >=20 >>> I'm obviously biased, but I think contrib/bmake/mk/options.mk is = close >>> to what is desired - just the mechanism with no policy. >>=20 >> I=3D92ve created a bsd.srcopt.mk and adjusted bsd.own.mk in a sample = patch, s=3D >> ince >> it sounds like we=3D92re headed in the right direction. Please take a = look at=3D >> it and >> let me know what you think. >=20 > Thanks >=20 >> http://people.freebsd.org/~imp/patch-queue/bsd.srcopt.mk >>=20 >> contains the patch and commit message (if I did the queue management = right) >> that I=3D92d like to proffer. >=20 > I could be miss-reading this, but it looks like you moved the list of > options to bsd.srcopt.mk ?=20 > That's not what I was suggesting, though I can see how it might be = useful. This was step one: separate out the options processing from the = bsd.own.mk stuff. Having a few lines that are generic would be nice to include. I=92d like = to go ahead and commit step 1, even if we refine things a bit later to keep the change = sets manageable and under control=85 Is that reasonable? It will help other areas and we = don=92t need to do much more than settle on filenames. :) > I was specifically thinking of a makefile that does not define/know = any > options at all. You set a list of options and include it and > it does the WITH[OUT]_* -> MK_* dance. > Eg. contrib/bmake/mk/options.mk consumes OPTIONS_DEFAULT_* but does = not > set even a default list. If you include it with no options list, it > does nothing - pure mechanism. Yea, that was the notion of the next step. > Now it might be very useful to extract the list of src options from > bsd.own.mk to something safer to include anytime. > But it is still (I think) useful to separate the options processing > from their definition. Yea, this is just the first step. > Eg. something like: >=20 > bsd.own.mk > .include > defines a bunch of options=20 > .include > sets MK_* based on WITH[OUT]_* for the list of > options provided >=20 > or per my comments below about installing, perhaps the list of options > etc might be better in src.options.mk (ie something we don't install? > I just thought of that so take with grain of salt) Yea, I have some concerns about going that far. See below. > Regardless, it might be handy to see the full files, to get a clearer > picture.=20 >=20 >> earlier in this thread. I=3D92m not tied to what I=3D92ve posted = here, but I wo=3D >> uld >> like to reach resolution so I can fix some other things in the build = without >> much delay. >=20 > Sure. >=20 >>=20 >>>> Where would the src build pick this up from if =3D3D >>>> it isn=3D3D92t installed? >>> =3D >>=20 >>> src/share/mk should work fine. >>=20 >> OK. I haven=3D92t added it to the Makefile so it gets installed, and = things >> seem to build, but that=3D92s not a viable way to commit things. = Please comme=3D >> nt >> on what I=3D92ve done and what you think the right way to proceed = might be. >> The easy path is, of course, just installing it :) >=20 > Sorry, which file are you talking about?=20 My bsd.srcopts.mk was what I was talking about here needing to be added = to share/mk/Makefile. > FWIW I think all bsd.*.mk should get installed. > but I think it perfectly reasonable to declare that anything matching = the > pattern local.* or src.* doesn't get installed. > Hopefully that shouldn't surprise anyone either. IF we can achieve that separation, then great. > To restate that slightly differently, you can think of these things as = a > hierarchy: >=20 > bsd.* mechanism for building stuff (not just /usr/src) > src.* stuff just for building /usr/src > local.* local tweaks to all the above Yes, as long as the MK_FOO variables that are really src building stuff = don=92t infect the bsd.foo.mk files, this could work out. Keeping the infection = rate down might be hard, but not impossible to manage. Would we do a wholesale change of bsd.foo.mk to src.foo.mk for all the = Makefiles in the tree if we went down this path? Or would the src.XXX stuff just = be for the orchestration we do between the different directories and such and we=92d = continue to build them the way we always have? >>> Not necessarily. The stuff in bsd.own.mk like: >>> =3D >>=20 >>> .if ${MK_TOOLCHAIN} =3D3D=3D3D "no" >>> MK_BINUTILS:=3D3D no >>> MK_CLANG:=3D3D no >>> MK_GCC:=3D3D no >>> MK_GDB:=3D3D no >>> .endif >>> =3D >>=20 >>> doesn't need to change, and for more elaborate stuff, simply being = able >>> to include *options.mk more than once may help quite a bit. >>=20 >> That might be hard, since MK_FOO being set from the first time = won=3D92t >=20 > Unless MK_FOO is set on make's commandline, you can override it any = time > you like - whether that makes sense or whether it gives people = headaches > is another matter. >=20 > Most of the current options seem to be more about whether certain > features/apps etc should be built. Changing the value of such = options=20 > once set doesn't make a lot of sense. eg. no point building libfoo > without support for goop, and then building food with a need for it. Yea. That does make a certain amount of sense. > The sorts of knobs more likely to be useful to tweak as we go, are = those > that affect how we do building (cf. configuring src), so MK_CTF, > MK_META_MODE, and probably many others we could come up with if the > mechanism were sufficiently flexible and easy to grok. Yea, I=92m not too hung up on the edge cases, but want to make sure that = we know the limitations going into this. Warner >>> No, but could do so pretty quickly. >=20 > Sorry I lied... ;-) >=20 >> I opted for a different name to not conflict. >=20 > Probably best. >=20 > Thanks > --sjg >=20