Date: Wed, 16 Apr 2014 23:34:37 -0700 From: "Simon J. Gerraty" <sjg@juniper.net> To: Warner Losh <imp@bsdimp.com> Cc: Baptiste Daroussin <bapt@freebsd.org>, freebsd-arch@freebsd.org, sjg@juniper.net Subject: Re: make WITH[OUT]_* more useful? Message-ID: <20140417063437.3BBF85809E@chaos.jnpr.net> In-Reply-To: <DC1B53C9-AF5F-4CF7-A369-5881C71E7F77@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> <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>
next in thread | previous in thread | raw e-mail | index | archive | help
>> 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, s= >ince >it sounds like we=92re headed in the right direction. Please take a look at= > it and >let me know what you think. Thanks >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. I could be miss-reading this, but it looks like you moved the list of options to bsd.srcopt.mk ? That's not what I was suggesting, though I can see how it might be useful. 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. 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. Eg. something like: bsd.own.mk .include <bsd.srcopt[s].mk> defines a bunch of options .include <bsd.mkoption[s].mk> sets MK_* based on WITH[OUT]_* for the list of options provided 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) Regardless, it might be handy to see the full files, to get a clearer picture. >earlier in this thread. I=92m not tied to what I=92ve posted here, but I wo= >uld >like to reach resolution so I can fix some other things in the build without >much delay. Sure. > >>> Where would the src build pick this up from if =3D >>> it isn=3D92t installed? >> = > >> 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 comme= >nt >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 :) Sorry, which file are you talking about? 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. To restate that slightly differently, you can think of these things as a hierarchy: bsd.* mechanism for building stuff (not just /usr/src) src.* stuff just for building /usr/src local.* local tweaks to all the above >> Not necessarily. The stuff in bsd.own.mk like: >> = > >> .if ${MK_TOOLCHAIN} =3D=3D "no" >> MK_BINUTILS:=3D no >> MK_CLANG:=3D no >> MK_GCC:=3D no >> MK_GDB:=3D no >> .endif >> = > >> 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 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. Most of the current options seem to be more about whether certain features/apps etc should be built. Changing the value of such options 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. 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. >> No, but could do so pretty quickly. Sorry I lied... ;-) >I opted for a different name to not conflict. Probably best. Thanks --sjg
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20140417063437.3BBF85809E>