Re: error: yacc.h: No such file or directory

On Wed, Jun 19, 2019 at 9:31 AM Rodney W. Grimes <
freebsd-rwg_at_gndrsh.dnsmgr.net> wrote:

> > In message <fffbe5d47e3515c960429ab416bf2ba234f9671d.camel_at_freebsd.org>
> > , Ian Le
> > pore writes:
> > > On Tue, 2019-06-18 at 07:01 -0700, Enji Cooper wrote:
> > > > > On Jun 18, 2019, at 06:59, Enji Cooper <yaneurabeya_at_gmail.com>
> > > > > wrote:
> > > > >
> > > > >
> > > > > > On Jun 18, 2019, at 06:53, Ian Lepore <ian_at_freebsd.org> wrote:
> > > > >
> > > > > ...
> > > > >
> > > > > > Last Saturday, Bryan (cc'd) made a series of commits
> (r349061-69)
> > > > > > that
> > > > > > were all somehow related to dependency processing in the
> > > > > > build.  I
> > > > > > don't know the details, just remember seeing some commits about
> > > > > > that.
> > > > >
> > > > > I remember that as well. This might have changed the dependency
> > > > > order subtly, introducing a race.
> > > > >
> > > > > The headers might not be built in all cases in time now.
> > > > >
> > > > > Thanks,
> > > > > -Enji
> > > > >
> > > > > PS This is one of the reasons why I wasn???t quick to discount
> Peter
> > > > > Jeremy???s reported build issue.
> > > >
> > > > Correction: I meant Julian Stacey.
> > >
> > > Julian Stacey has 3 problems:
> > >
> > >  1. Missing opt_cam.h
> > >  2. Missing yacc.h
> > >  3. A years-long inability to report a problem without hurling personal
> > > insults at the project and everyone associated with it.
> > >
> > > Because of #3, I don't much care about 1 and 2.
> >
> > Bingo! My point exactly!
>
> You can't understand the frustration of 25 years of
> having system build breakage on a pretty regular basis
> as a trigger point for anger?
>

If there really were 25 years of constant build breakages, then maybe. But
this overstates the number of times it happens. In the past 10 years the
number of tree breakages is 10x or more fewer than in the early days of the
project when it was all the time. In the interim, we've grown a bunch of
new ways to build, and the combinatorics make it impossible to exhaustively
test. No matter what we do, things will break, despite people's best
efforts. Getting table flipping mad is an over-reaction and frankly not
actionable. If you look at the breakage lately, in general it's been in
weird edge cases that not too many people do on a regular basis.

Missing opt_cam.h was only for the not-with-the-kernel build path. It's
supposed to work, but it breaks more often than other paths because it's
significantly less used. This specific issue was actually fixed before
Julian complained as well, so we caught it fairly quickly (I fixed it 5
days after it went in). We should take this as a signal that this feature
isn't used much used, not as an opportunity to vent one's spleen. It's not
even in the CI path today. Had it been, we'd have caught it faster. We hit
this from time to time, so having it be in CI likely makes some sense.

The yacc.h was an unforeseen side effect of improvements in other
dependency parsing that sped up the build. And it was only for the non -j X
/ -B case. Since clang takes forever to build, nobody builds w/o -j #, so
it went unnoticed for a few days. Since it takes a fairly beefy machine to
build FreeBSD, this is an understandable oops. This one I'm not sure we
should put into CI very often since it's a tricky bug to catch and it's
quite rare that we have ordering issues that get tripped up by -j vs no -j.
There's only so many CI resources, and given the problems in the area, I
think it's a poor ROI.

Warner