Date: Thu, 17 Apr 2014 10:30:58 -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: <06CC1B46-2BF2-439C-8F97-16EA8DD7805C@bsdimp.com> In-Reply-To: <20140417063437.3BBF85809E@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> <DC1B53C9-AF5F-4CF7-A369-5881C71E7F77@bsdimp.com> <20140417063437.3BBF85809E@chaos.jnpr.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Apr 17, 2014, at 12:34 AM, Simon J. Gerraty <sjg@juniper.net> 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 <bsd.srcopt[s].mk> > defines a bunch of options=20 > .include <bsd.mkoption[s].mk> > 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?06CC1B46-2BF2-439C-8F97-16EA8DD7805C>