[build2] Yacc module?

[Boris Kolpackov]

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]).

While proper documentation for the build system modules is coming,
one requirement to keep in mind is that they must be built in a build
configuration that does not overlap with the one that tries to use
the module (since the module is built in a separate nested build
context). So we are still figuring out the best way to arrange
things in a module implementation.


> I'd be interested in diving into this to create at least a basic structure
> -- I won't promise to support a lot of platforms as that seems like a
> particularly daunting task. Hopefully others will be able to step in.

That sounds good.


> I was thinking of just starting with yacc as specified by POSIX for the
> time being, i.e. C only and no GNU extensions. From my experience on macOS,
> bison does a decent job of emulating yacc. My platforms would be Fedora,
> macOS, OpenBSD and eventually Windows.
> 
> Even so, I can think of a number of challenges:
> 
>  1. Anywhere from one to three output files with limited naming options.

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.

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}


>  2. I frequently need to modify compiler options for yacc output, e.g.
>     disable warnings. How would the build2 philosophy handle this?

obj{foo.tab...}: c.coptions += ...


>  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


>  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.

[1] https://github.com/boris-kolpackov/libbuild2-hello
[2] https://github.com/build2/build2/tree/master/build2/cli