Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 17 Apr 2014 20:57:31 -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:  <18D76DD4-AA14-46CB-8D41-6176D08FA56F@bsdimp.com>
In-Reply-To: <20140417220633.242585809F@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> <06CC1B46-2BF2-439C-8F97-16EA8DD7805C@bsdimp.com> <20140417181159.0EFEA5809E@chaos.jnpr.net> <7C527DA8-ABC0-4D6A-AACB-64D89246B569@bsdimp.com> <20140417220633.242585809F@chaos.jnpr.net>

next in thread | previous in thread | raw e-mail | index | archive | help

On Apr 17, 2014, at 4:06 PM, Simon J. Gerraty <sjg@juniper.net> wrote:

>=20
> On Thu, 17 Apr 2014 14:29:28 -0600, Warner Losh writes:
>>> bsd.own.mk -> bsd.srcopts.mk -> bsd.mkopts.mk
>>=20
>> Since we=3D92re planning a src.opts.mk at some point (to control =
/usr/src bui=3D
>> lds),
>> the bsd.srcopts.mk name seems to have a short shelf life. Maybe just =
bsd.op=3D
>> ts.mk?
>=20
> Sure bsd.opts.mk sounds fine.

Done.

>>> .-include "src.sys.mk"
>>> .-include "local.sys.mk"
>>> =3D
>>=20
>>> that would be sufficient to enable all sorts of cool stuff.
>>=20
>> In non-posix mode, sure. This would be the natural place for
>> the MK option setting. While it is early, it isn=3D92t too bad. It =
works
>> great for buildworld scenarios, since we have a well-defined
>> location for src.sys.mk. It works less well for the individual src
>> Makefiles that might need to access variables set in src.sys.mk,
>> which becomes unfindable w/o extra args on the command line,
>> or requires knowledge of where the Makefile lives in the tree
>> to reach over and snag it.
>=20
> I've avoided that issue for ages by using a wrapper script to =
condition
> the env for the tree I'm working in, junos freebsd, netbsd etc.
> If all your trees have a share/mk, that you want to use you can just=20=

> export MAKESYSPATH=3D".../share/mk"
> and bmake will DTRT.

Can that be set in a Makefile?

>>> Similarly, bsd.init.mk doing
>>> =3D
>>=20
>>> .-include "src.init.mk"
>>> .-include "local.init.mk"
>>> =3D
>>=20
>>> would allow for customization of things to be done after Makefile =
has
>>> been read. =3D
>>=20
>> What would go there? Or would they be empty place holders?
>=20
> It depends.  Some things need to be done after Makefile has been read
> (rather than before) - eg any variable ref on rhs of dependency rule
> needs to have a value at that time.
>=20
> Let's say I wanted to be able to build head in meta mode (rather than
> keep syncing to projects/bmake).
> If there were suitable local.*.mk hook points I could do that without
> affecting anyone else, until such time as I can convince others that =
its
> a brilliant idea ;-)
>=20
> Even if FreeBSD.org decide they want to build /usr/src in
> meta mode, that doesn't mean that every user of FreeBSD wants all =
their
> own projects to build that way.  Some of the glue I had in local.*.mk
> could move to src.*.mk so that /usr/src could leverage it without
> impacting every user of bsd.*.mk
>=20
> That's just one example of course.

OK. I=92m sold.

>> Also missing is a defined place for users to define WITH/WITHOUT_FOO.
>=20
> You can still support {src,local,make}.conf

OK. Will keep it around.

>> True, but it looks like it may make in-tree use in the =
non-build-world case=3D
>> more complicated. There may be some resistance to that.
>=20
> I'm not sure it would impact one way or the other.
> It all boils down to whether /usr/share/mk, -m * or $MAKESYSPATH
> are used.
>=20
> I would figure anyone inclined to go adding local.*.mk to their tree,
> would be able to cope with setting MAKESYSPATH or whatever else it =
takes
> to do what they want.

Yea, I agree for local.*.mk, but the case is less clear for src.*.mk =
which is
now required for the build=85 I should do a census on the number of =
files this affects.

I=92ll post patches as soon as I finish make universe.

Warner




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?18D76DD4-AA14-46CB-8D41-6176D08FA56F>