Date: Tue, 15 Apr 2014 20:27:49 -0600 From: Warner Losh <imp@bsdimp.com> To: "Simon J. Gerraty" <sjg@juniper.net> Cc: Baptiste Daroussin <bapt@freebsd.org>, freebsd-arch@freebsd.org Subject: Re: make WITH[OUT]_* more useful? Message-ID: <DC1B53C9-AF5F-4CF7-A369-5881C71E7F77@bsdimp.com> In-Reply-To: <20140410034645.C058658097@chaos.jnpr.net> References: <20140401051327.F20F958097@chaos.jnpr.net> <20140401064316.GQ99393@ivaldir.etoilebsd.net> <766EFF76-7B41-423F-B447-DBA25BD14470@bsdimp.com> <20140401162912.7A9D058097@chaos.jnpr.net> <DBA8EC5A-0C9A-4EED-94CC-178BBAFA29DB@bsdimp.com> <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>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi Simon, On Apr 9, 2014, at 9:46 PM, Simon J. Gerraty <sjg@juniper.net> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?DC1B53C9-AF5F-4CF7-A369-5881C71E7F77>