svn commit: r288911 - head/share/mk

[Warner Losh]

> On Oct 6, 2015, at 12:02 PM, Bryan Drewery <bdrewery at 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.freebsd.org/pipermail/svn-src-all/attachments/20151006/7fb02972/attachment.bin>