[build2] Yacc module?

[Joachim Kuebart]

On Mon, 2 Sep 2019 at 14:40, Boris Kolpackov <boris at codesynthesis.com> wrote:
>
> Joachim Kuebart <joachim.kuebart at gmail.com> writes:
>
> > Ok, I've upgraded to -stage and built libbuild2-hello, but haven't
> > been able to load the resulting module yet -- the test doesn't seem to do
> > that, does it?
>
> It wasn't but I've now reworked it a bit including a proper test (and
> instructions in the project's README[1]).

Thanks, that was a very quick and thorough rework.

> Yes, multiple/variable output set won't be a problem (merely a
> complication). I also think we should skip the fixed file name
> output (y.tab.c) and go straight to prefix/-b.

I agree, it should by y{foo} -> foo.y, foo.tab.c, foo.tab.h and
foo.output -- quite straightforward actually ;-)

> The cli module[2] handles all of this though I am a bit reluctant
> to suggest it as an example since it's quite complex (due to
> supporting being optional, etc) and also could use a bit of
> cleanup.
>
> But I think the target type and the rule implementations are ok.
> Though I am not sure we need to support specifying dependencies
> as individual files, I think starting with group-only makes sense:
>
> exe{main}: cxx{main} tab{foo}
> tab{foo}: y{foo}

I've started with the yacc module[0], but I'm not claiming to really
understand what I'm doing yet ;-). I'm currently stuck where none of
my compile_rule's methods are being called by the test even though I
added y{**} and a corresponding file.. will need to look into that
later.

> >  3. A library -ly is usually needed when linking yacc output, how would
> >     this best be handled?
>
> If you assume it's supplied by the system (similar to -ldl, etc), then:
>
> c.libs += -ly

That works of course, I was thinking whether there would be a way of
automatically adding that whenever a .y file is an (indirect)
dependency. But perhaps too much automation is not such a good idea
either.

> >  4. How should the dependency on yacc be handled? System dependency?
> >     Package it?
>
> That's a good question. It can actually be both. I think if we decide
> to package something, then we should just do GNU bison (hopefully it
> builds on Windows).
>
> It probably makes sense to start with assuming yacc/-ly comes from
> the system.

On the "yacc" branch [1], I have included a OpenBSD's yacc which has
no dependencies except for one OpenBSD library function which I also
included. I haven't looked at libyacc yet though. If we were to go
down the route of including yacc, I think it should be installed
somewhere out of the user's path (i.e. libexec/) and called directly.
The advantage would be that it would work and work the same on all
platforms. The disadvantage would be that it wouldn't use the user's
own yacc/bison/... in case they wanted to use some special features.

Cheers,

Joachim

[0] https://gitlab.com/jkuebart/libbuild2-yacc/tree/libbuild2-yacc
[1] https://gitlab.com/jkuebart/libbuild2-yacc/tree/yacc