Re: buildworld fails (missing /usr/share/mk/src.opts.mk)

Am 06.05.2014 16:28, schrieb Warner Losh:
> First off, thanks for looking into this. Build issues are no fun. :(
> On May 6, 2014, at 8:11 AM, Stefan Esser <se_at_freebsd.org> wrote:
>> Am 06.05.2014 15:18, schrieb Warner Losh:
>>> On May 6, 2014, at 7:16 AM, Warner Losh <imp_at_bsdimp.com> wrote:
>>>> On May 6, 2014, at 6:39 AM, Stefan Esser <se_at_freebsd.org> wrote:
>>>>> Am 06.05.2014 13:44, schrieb Trond Endrestøl:
>>>>>> On Tue, 6 May 2014 13:24+0200, Stefan Esser wrote:
>>>>>>> Am 06.05.2014 11:52, schrieb Stefan Esser:
>>>>>> tinderbox still complains about usr.bin/bmake/Makefile.inc.
>>>>>
>>>>> Hmmm, I managed to buildworld -HEAD after this patch, but it
>>>>> is possible, that I had src.opts.mk installed in /usr/share/mk
>>>>> when I started the build.
>>>>>
>>>>> (I later deleted it, to be sure that the version in the source 
>>>>> directory was found and used when building modules, which the 
>>>>> commit actually fixed.)
>>>>>
>>>>> I guess the remaining problem is caused by
>>>>>
>>>>> .include "src.opts.mk"
>>>>>
>>>>> in line 3 of src/usr.bin/bmake/Makefile.inc
>>>>>
>>>>> Changing this line to read ".include <src.opts.mk>" seems to
>>>>> fix it on my system.
>>>>>
>>>>> --- usr.bin/bmake/Makefile.inc~ +++ usr.bin/bmake/Makefile.inc 
>>>>> _at__at_ -1,6 +1,6 _at__at_ # $FreeBSD$
>>>>>
>>>>> -.include "src.opts.mk" +.include <src.opts.mk>
> 
> This change I think actually is right. And it needs to be an ‘sinclude’
> to support the fmake upgrade path, but I need to double check that
> can’t be worked around in the environment.

Yes, the upgrade path is broken and that is what the tinderbox builds
complain about.

I just verified this by installing fmake as make on -HEAD. It fails
to build bmake as reported by tinderbox.

>>>> What is your source system? This is absolutely the wrong change,
>>>> and shouldn’t be necessary at all. These changes survived a
>>>> universe run and a few build worlds on other systems.
>>
>> I'm on a fresh -CURRENT (built the previous day) and with sources
>> as of r265439.
> 
> OK. My current is a bit dated, so I’ll spin up a new one.

I guess there are less problems when starting with -CURRENT than if
you come from 9-STABLE, so that appears to be the better test.

>> I agree, that the change to bmake/Makefile.inc was wrong - though
>> it was needed to get a "make cleandir" working in that directory.
> 
> Yea, I’m trying to get one that works all the time… I think I have it
> which should silence the tinderboxes…  In hind sight, perhaps
> I should have pushed this in first thing this morning rather than
> last thing last night...

Well, it was early morning in this part of the world, when the
tinderbox mails started to arrive ;-)

But the change (separation of src options and corresponding logic)
is definitely worth the nuisance of temporary breakage ...

>>> <hit send too fast>
>>>
>>> so I’d like to know how to recreate it, since I didn’t see this in
>>> any of my testing over the last two weeks...
>>
>> The tinderbox builds all fail in bmake, and while I changed
>> Makefile.inc to fix just that kind of problem on my system, it
>> may have worked by accident (because of a forgotten src.opts.mk
>> in /usr/share/mk - it had been installed by a previous attempt
>> to work around these problems).
> 
> The initial bootstrap of bmake, or the later build of bmake? I was
> able to reproduce the former, but haven’t seen the latter fail.

Yes, it always seems to be the initial build that fails. And that
phase is skipped on systems with a usable bmake ...

>> To recapitulate the order of events:
>>
>> 1) make buildkernel failed due to 2 missing includes of
>>   src.opts.mk. The affected files files were:
>>
>> 	sys/conf/kmod.mk
>> 	sys/modules/drm2/Makefile
>>
>>   Adding an .include <src.opts.mk> seems to have fixed this
>>   problem. Maybe "src.opts.mk" would have been more correct,
>>   but I checked without src.opts.mk in /usr/share/mk and the
>>   file was found in src/share/mk.
> 
> I’ll look at these. I might have introduced the issues after I stopped
> building the 75 kernels in make universe after I made it through once.
> My bad...
> 
>> 2) tinderbox still complained about the test for MK_SHARED_TOOLCHAIN
>>   in bmake/Makefile.inc (I deleted the mails and thus cannot
>>   easily quote the exact error message). I tried to fix this by
>>   changing the include syntax in bmake/Makefile.inc, but have
>>   just reverted this change. It made buildworld complete on my
>>   system, but tinderbox complains loudly.
> 
> I’ll look at this as well...
> 
>> A work-around for the second problem is to manually install
>> src.opts.mk in /usr/share/mk before attempting to build bmake.
> 
> Yea, and we don’t really want to do that. The other workaround is
> mentioned in updating… Setting MAKESYSPATH. I need to make
> sure my testing wasn’t contaminated with this somehow.

Ahh, I missed that entry in UPDATING ...

But if I had read it, I'd missed the hint that MAKESYSPATH can be
used to unbreak buildworld. The text just mentions incremental
builds.

Anyway, if .sinclude "src.opts.mk" really works in all cases, all
should be good again :)

Regards, STefan