Date: Tue, 6 Oct 2015 14:24:24 -0600 From: Warner Losh <imp@bsdimp.com> To: Bryan Drewery <bdrewery@freebsd.org> Cc: Warner Losh <imp@FreeBSD.org>, src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: Re: svn commit: r288911 - head/share/mk Message-ID: <8D5D1CE5-BC57-464D-9C47-63EFF4C1CF2F@bsdimp.com> In-Reply-To: <56140CAD.8080200@FreeBSD.org> References: <201510060418.t964Innu071170@repo.freebsd.org> <56140CAD.8080200@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
[-- Attachment #1 --] > On Oct 6, 2015, at 12:02 PM, Bryan Drewery <bdrewery@freebsd.org> wrote: > > On 10/5/2015 9:18 PM, Warner Losh wrote: >> Author: imp >> Date: Tue Oct 6 04:18:48 2015 >> New Revision: 288911 >> URL: https://svnweb.freebsd.org/changeset/base/288911 >> >> Log: >> Previous versions of bsd.own.mk included bsd.compiler.mk >> only when _WITHOUT_SRCCONF wasn't defined. Restore this >> behavior because bsd.ports.mk depends on this in subtle >> ways. The compat include of bsd.compiler.mk should >> be removed in 12 anyway. >> >> PR: 203540 >> > > Perhaps the wrong place to discuss this, but I will anyhow as I don't > think it will change. > > The sys.mk change to include src.conf breaks building ports in a sub-dir > of src. Meaning, /usr/src/ports/. The MAKESYSPATH with '.../share/mk' > finds /usr/src/share/mk and runs off with all of the src.*.mk stuff long > before the port Makefile includes bsd.port.mk, from > /usr/src/share/mk/bsd.port.mk, which has a _WITHOUT_SRCCONF= guard set > on it to avoid bsd.own.mk from including src.conf. But because sys.mk > is already included long before this, src.conf is already included and > anything handled in sys.mk has no real way to respect _WITHOUT_SRCCONF > unless it is in the environment Yuck! But the real problem here is MAKESYSPATH of …/share/mk. That was a hack until we had something like SRCTOP that we could use for finding the right stuff and for individual builds. So if we can solve that part of the problem, we can get rid of the default …/share/mk definition. It wasn’t anticipated to be something forever, just something for the moment. > [Note that the actual inclusion of src.conf no longer has a > _WITHOUT_SRCCONF= check, but that is trivial to fix] That likely got lost in the shuffle. Agreed, it’s easier to add back in. > Why would anyone build ports in a sub-dir of src? It's convenient for a > vendor building their own product that needs their own ports tree. Some > decisions can't easily be changed; if the root of the source code > checkout is already src/, there is no simple way to avoid the problem. We do it too… It’s evil, but there you go. > With the META_MODE changes, sjg introduced this /etc/src-env.conf file > that is included from sys.mk early, that can be used for overriding > things like MAKEOBJDIRPREFIX, enabling META_MODE (it needs to be set > extremely early for AUTO_OBJ support, among other things). > > As far as I can tell, the sys.mk change to include src.conf early was > done out of convenience. Meaning, we could remove that and just add > back a .include <src.init.mk> or similar at the top of all src Makefiles. All src makefiles? Yea, I’d rather hoped to avoid that, though it is easily scripted. I’d thought of this solution at the time I did the MAKESYSPATH hack, and rejected it as being too unwieldy. And having that at the top of all the files would still require MAKESYSPATH need to be …/share/mk to work out. I was rather hoping we could find some good way around doing that. > I would really like to find a solution to this as it is a looming > problem for my work's build approaching in a few months. I figured out a > hack we can use locally, to set _WITHOUT_SRCCONF=, when the current > directory has "ports/" in it. That works for us, but not for other > vendors who don't realize this is coming. Perhaps the scope of people > doing this is not large. One trivial solution would be to only do ports sub-builds with _WITHOUT_SRCCONF defined. But like all good kludges, I imagine there’d be logistical issues with that. Warner [-- Attachment #2 --] -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJWFC34AAoJEGwc0Sh9sBEAEkQP/R8z7vjC4m6crEhhO1hQVCCD qHNbIL3qXGrM0IKTqJRTQ4GXLd1ep5394DhCbU3DhqY2GXyHp9HS0+GrIGv/9Kxz IVN821cDZwyPKjnK/nvoXfIfJdKs//GFRhDnX28BEW6CTIrQp9xoQR2DjCMNbsaT Ru+r/VGDyjv+ebT8Qs9fvBUQNO6zRlCuhyy0/BFjLck+JyfV62PSsE901ivMUkxx 33fqw/0VVlsbj4htQU4WV8RbexQwswwuDUxcnd9esz6hgttJ0A37K5tNi8mgr+i6 XOQhKJBwqJ4erJTZODotnaK5DglY3h6JhnPyWpwohixhb7O8YaGOuUB+15ohQrVF bfCPSP/YSNTN4OF/61BR1bqkjlDxgW7DTkYPmHyGs1iANALJal58DHxW4W73walf FZZTuiyxDHppLZp5dt/BLFAaVNe8cXeR98QaVa9WQLVBUF29YCkhNkMjlpPA9e58 5/ivIlcbe2+7cqZF0X4xg5L2mBNsGtfE5SFsMqRqIBxfMbg0jPSDmE6Q5/t2GjrC tWHT1G8shfBcgZTIIGETCOAReQA57kM7j8g1MUXsGAiaJbCinJ9yc4fw+MrxDDQw VOKpHecuS6C7cPfIPRtMsGkyEZzQHLFOVi7A8fJT1WCC1EiqkrwQfDiEWBhF05Hd LRncRi3iy6iFRpHiTpWW =vZzd -----END PGP SIGNATURE-----
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?8D5D1CE5-BC57-464D-9C47-63EFF4C1CF2F>