From owner-freebsd-arch@FreeBSD.ORG Wed Apr 16 02:28:00 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 773A3393 for ; Wed, 16 Apr 2014 02:28:00 +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 442BE1BDF for ; Wed, 16 Apr 2014 02:27:59 +0000 (UTC) Received: by mail-pa0-f43.google.com with SMTP id bj1so10359346pad.30 for ; Tue, 15 Apr 2014 19:27:53 -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=IO7Qzihqw2f9ZUKkqDeyjMHi+t5mEeYsvTa2iWwg0vU=; b=ShshdjCSIY70EBoPxavorMDHRB+nwtyfLTw+UehymvCrzJlliBcZoFD+qJ8LKim+M0 ZGrAVdb2npuo0h+yf+xWT5EXw9bsSqV7PQCDwvtDpWswp2uyw+i1ogecvBCLiZlTH4aa ghZ7jlLC7f2pI/nuPc7K+KnLxeWapBTiYW82u0Dykz9tvRpaL85+4PZmMPA5+GY1rvm3 x+rTNGco4uBVmxD9scO0dtqGEyBmO5dDcuQyqrhfy4x3nFJN6Ys+SYSpT/Yk4dQzJgwT MxgVMoaV5NFbCsTqgA/ubcAyh6GjAbqdbAcsyX9QErPqaoHr97A4bmolv2pKnyxzT88R L6Iw== X-Gm-Message-State: ALoCoQmRVFqZ8BhV46c6QzAxG/k0FTLIp0zky0r/2g2L/DJFRD6jQtxC00sr2BT1fLxgosHAeE/J X-Received: by 10.68.201.226 with SMTP id kd2mr5499832pbc.157.1397615272911; Tue, 15 Apr 2014 19:27:52 -0700 (PDT) Received: from macintosh-c42c033c0b73.corp.netflix.com (dc1-prod.netflix.com. [69.53.236.251]) by mx.google.com with ESMTPSA id nx12sm103628711pab.6.2014.04.15.19.27.51 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 15 Apr 2014 19:27:52 -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: <20140410034645.C058658097@chaos.jnpr.net> Date: Tue, 15 Apr 2014 20:27:49 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: 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> 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: Wed, 16 Apr 2014 02:28:00 -0000 Hi Simon, On Apr 9, 2014, at 9:46 PM, Simon J. Gerraty wrote: >> It sounds like we=3D92re in agreement on how to proceed, or very = nearly =3D >> so. I have some more >> comments below, but I think the next order of business would be = patches. =3D >> Do you have some ready to roll?=20 >=20 > No, not yet - I figured getting some level of consensus fist was > worthwhile. >=20 > My cunning plan was simply to remove the mechanism from bsd.own.mk, > and include the new file at approximately the original location. > Thus not necessarily any functional change. > The devil's in the details of course. >=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. I=92ve created a bsd.srcopt.mk and adjusted bsd.own.mk in a sample = patch, since it sounds like we=92re headed in the right direction. Please take a look = at it and let me know what you think. http://people.freebsd.org/~imp/patch-queue/bsd.srcopt.mk contains the patch and commit message (if I did the queue management = right) that I=92d like to proffer. If we can make this somehow more generic, I=92d be game, but we have = some fairly ugly interdependencies that may complicate a clean, simple = solution. >> If so, then we should iterate on them. If not, I can =3D >> find some time over >> the coming days/weeks. I=3D92d like to have this done before BSDcan, = but =3D >> if not we can >> chat then, assuming you are going. >=20 > Sounds good, yes I'll be there. >=20 >>> That's why I'd put such things in local.sys.mk or some other = makefile >>> that affects /usr/src but isn't install into /usr/share/mk/ >>=20 >> That=3D92s a bit of a departure over how we=3D92ve done things, but = one that =3D >> may make a good amount of sense.=20 >=20 > I've been distributing my *.mk files for a long time, and I prefer > people leave them as is, so I make it easy for them to customize = without > hacking. Adding .-include "local.*.mk" allows for a lot of > customization. > When I wrote dirdeps.mk et al it was with the understanding that = Juniper > would make them publicly available, so used the same model. >=20 > IIRC there was some discussion at dev summit or BSDCan last year about > having src/ look for src.conf, make.conf etc inside the tree rather = than > /etc. I know in our internal builds we want to ensure that our src/ = is > self contained. Yea, we can work out the policy mechanism for this. I was kinda hoping to be able to use this tool to fix the NO_CTF issue that we talked about earlier in this thread. I=92m not tied to what I=92ve posted here, but I = would like to reach resolution so I can fix some other things in the build = without much delay. >> Where would the src build pick this up from if =3D >> it isn=3D92t installed? >=20 > src/share/mk should work fine. OK. I haven=92t added it to the Makefile so it gets installed, and = things seem to build, but that=92s not a viable way to commit things. Please = comment on what I=92ve done and what you think the right way to proceed might = be. The easy path is, of course, just installing it :) >>> Wouldn't it be simpler to set MK_CTF=3D3Dno *before* including =3D >> bsd.own.mk ? >>=20 >> Well, kinda=3D85 Then the issue becomes, in what I think you are =3D >> proposing, what happens >> to the meta variables, or MK_foo that sets a lot of MK_bar. Assuming = we =3D >> move all of >> them to their own file, we have two sections. One that sets MK_xxx =3D >> variables based on >> WITH/WITHOUT, and a second one that sets them based on other MK_xxx =3D= >> variables. >> If I set MK_CTF=3D3Dno in my makefile, and it caused other MK_ flags = to be =3D >> set, then I=3D92d have >> to include something to take another run at setting those =3D >> meta-variables. >=20 > Not necessarily. The stuff in bsd.own.mk like: >=20 > .if ${MK_TOOLCHAIN} =3D=3D "no" > MK_BINUTILS:=3D no > MK_CLANG:=3D no > MK_GCC:=3D no > MK_GDB:=3D no > .endif >=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. That might be hard, since MK_FOO being set from the first time won=92t allow us to override them the second or further time. I opted for a = guard target in my rendition, but now that I think about it, I=92m not so sure = that=92s needed and multiple include would allow us to remove the current restriction that you can=92t toggle MK_META from =93no=94 to =93yes=94 = after we=92ve included the option.mk file. >>> Yes, that's essentially what I was proposing. >>> By extracting the mechanism to its own file, it can be re-used. >>=20 >> Do you have patches? I think I like it... >=20 > No, but could do so pretty quickly. > I need to resync projects/bmake and start writing my material for = BSDCan > ;-) I could look doing this as part of that. >=20 > The hardest bit is naming the new makefile ;-) > bsd.options.mk would be an obvious choice - though that conflicts with > ports usage. Yea, I chose bsd.srcopt.mk for my doodles. >>> Calling it bsd.options.mk is a conflict with ports. >>> Though including it as "bsd.options.mk" both in bsd.own.mk and in = the >>> relevant ports makefile, should probably mitigate that. >>=20 >> I thought ports used a different mechanism and defined special magic = so =3D >> the >> src tree mechanism was disabled. >=20 > The ports makefile is much more elaborate but I believe achieves = similar > results. The name conflict could probably be worked around if > bsd.options.mk is considered the best name choice. I opted for a different name to not conflict. Warner