Building Bison

[Daniele Nicolodi]

Hello,

I would like to include Bison as a subproject in my project. Has anyone
tried to write a Meson build definition for it?

I may find enough motivation and time to do it myself. Does anyone have
experience with porting a typical autotools build system for a project
using gnulib to Meson? How much effort should I anticipate?

Thank you.

Cheers,
Dan

[John Scott]

> Does anyone have experience with porting a typical autotools build system
> for a project using gnulib to Meson?

Are you asking about building Bison, the parser generator itself, with Meson?
Your time would probably be better spent working with the Autotools build
system or using Meson to wrap around it, but I don't think that would need
to be very particular to Bison.

I do have some findings from exploring the use of Gnulib directly in a Meson
project for portability purposes, but it's not relevant to software that
already embeds it.

If you mean using Meson to generate a parser from source using Bison,
that's a different matter. If your parser is yacc-compatible, maybe byacc
would be easier?

[Jussi Pakkanen]

On Sat, 19 Dec 2020 at 22:06, Daniele Nicolodi <dan...@grinta.net> wrote:

> I would like to include Bison as a subproject in my project. Has anyone
> tried to write a Meson build definition for it?

I remember trying that for Flex and Bison. I don't remember which but
one of the two is not actuallywritten in C but something like M4 and
the C main is just a shim that runs the script code that is embedded
in the exe. The dependency tree exploded and I got frustrated and
stopped working on it.

> I may find enough motivation and time to do it myself. Does anyone have
> experience with porting a typical autotools build system for a project
> using gnulib to Meson? How much effort should I anticipate?

It depends on the implementation a fair bit. "Pure" C programs are
fairly straightforward, problems appear if the program has complex
configuration settings (GLib as an extreme example) or it does source
generation or the like especially if it also requires something like
an in-source build because it assumes its input files are, say, in the
same directory as the generator program.

[Daniele Nicolodi]

On 20/12/2020 13:26, Jussi Pakkanen wrote:
> On Sat, 19 Dec 2020 at 22:06, Daniele Nicolodi <dan...@grinta.net> wrote:
>
>> I would like to include Bison as a subproject in my project. Has anyone
>> tried to write a Meson build definition for it?
>
> I remember trying that for Flex and Bison. I don't remember which but
> one of the two is not actuallywritten in C but something like M4 and
> the C main is just a shim that runs the script code that is embedded
> in the exe. The dependency tree exploded and I got frustrated and
> stopped working on it.

I fear this may be Bison, AFAIK Flex does not depend on m4. Do you
recall which other dependencies m4 brought along? Do you still have some
Meson code that you could share?

I use RE-flex as a scanner generator, and I recommend it as a modern
substitute for Flex. Despite producing C++ code, it has a mode in which
it outputs the same API as Flex, thus it is an (almost) zero cost
replacement. I a have Meson build definition for RE-flex which I plan to
submit to WrapDB.

>> I may find enough motivation and time to do it myself. Does anyone have
>> experience with porting a typical autotools build system for a project
>> using gnulib to Meson? How much effort should I anticipate?
>
> It depends on the implementation a fair bit. "Pure" C programs are
> fairly straightforward, problems appear if the program has complex
> configuration settings (GLib as an extreme example) or it does source
> generation or the like especially if it also requires something like
> an in-source build because it assumes its input files are, say, in the
> same directory as the generator program.

Thank you Jussy.

PS: I have been enjoying your "The Meson Manual" book. Thank you for
writing it and for the recent update. I am disappointed that it did not
turn out to be a self sustaining activity.

Cheers,
Dan

[Jussi Pakkanen]

On Sun, 20 Dec 2020 at 16:41, Daniele Nicolodi <dan...@grinta.net> wrote:

> > I remember trying that for Flex and Bison. I don't remember which but
> > one of the two is not actuallywritten in C but something like M4 and
> > the C main is just a shim that runs the script code that is embedded
> > in the exe. The dependency tree exploded and I got frustrated and
> > stopped working on it.
>
> I fear this may be Bison, AFAIK Flex does not depend on m4. Do you
> recall which other dependencies m4 brought along? Do you still have some
> Meson code that you could share?

I don't think I got any code actually written. When I dove into the
deps something weird came up (like maybe M4 build-depending on itself
or something) and I just stopped.

> I use RE-flex as a scanner generator, and I recommend it as a modern
> substitute for Flex. Despite producing C++ code, it has a mode in which
> it outputs the same API as Flex, thus it is an (almost) zero cost
> replacement. I a have Meson build definition for RE-flex which I plan to
> submit to WrapDB.

There is also Lemon, which is part of SQLite and which should be fairly good.

> PS: I have been enjoying your "The Meson Manual" book. Thank you for
> writing it and for the recent update. I am disappointed that it did not
> turn out to be a self sustaining activity.

Thanks, nice to know it has been useful.

[Daniele Nicolodi]

On 21/12/2020 15:29, Jussi Pakkanen wrote:
> On Sun, 20 Dec 2020 at 16:41, Daniele Nicolodi <dan...@grinta.net> wrote:
>
>>> I remember trying that for Flex and Bison. I don't remember which but
>>> one of the two is not actuallywritten in C but something like M4 and
>>> the C main is just a shim that runs the script code that is embedded
>>> in the exe. The dependency tree exploded and I got frustrated and
>>> stopped working on it.
>>
>> I fear this may be Bison, AFAIK Flex does not depend on m4. Do you
>> recall which other dependencies m4 brought along? Do you still have some
>> Meson code that you could share?
>
> I don't think I got any code actually written. When I dove into the
> deps something weird came up (like maybe M4 build-depending on itself
> or something) and I just stopped.

I had a look at the config.h.in of Bison. While it does not seem to
contain anything particularly difficult to detect in Meson, actually
writing all the required configuration code would be extremely tedious.
I don't think I'll embark in this project just now.

I have been looking into using the "external_project" module to use the
Bison autotools based build system in a subproject. However, reading the
documentation, it seems that it explicitly forbids using executables
built in this way in the build. I am not sure I understand why. In the
case of Bison, for example, running the 'bison' executable from the
build directory works just fine. What am I missing?

Cheers,
Dan