Re: Meson build definition

[Daniele Nicolodi]

On 20/12/2020 15:31, Christian Schoenebeck via Users list for the GNU
Bison parser generator wrote:
> On Sonntag, 20. Dezember 2020 12:33:45 CET Daniele Nicolodi wrote:
>> On 20/12/2020 08:09, Akim Demaille wrote:
>>> Hi Daniele,
>>>
>>>> Le 19 déc. 2020 à 20:17, Daniele Nicolodi <daniele@grinta.net> a écrit :
>>>>
>>>> Hello,
>>>>
>>>> I am working on a project that uses Bison to generate a parser and Meson
>>>> as build system. I would like to include Bison as a subproject [1] in
>>>> particular to make it easier for folks to hack on the project on OSes
>>>> where managing dependencies is not easy (ie Windows).
>>>
>>> I believe chocolatey addresses that issue.  And people who want to hack
>>> Bison should certainly be able to use their Unix subsystem.
>>
>> I realize I was not very clear: I meant working on my project (ie
>> modifying the parser) not hacking on Bison itself. I agree that using
>> the Bison main build system while working on Bison itself is a fair
>> expectation.
> 
> It's indeed somewhat confusion what you're goal is. If I got you correctly,
> your scenario are systems where Bison is already installed, and you just want
> Meson deployed projects being able to just add '.y' sources files to their
> meson.build file for them to be auto generated by Bison.

I want to build Bison as a subproject to be able to use it for
generating a grammar as part of my project. I thought that "I want to
include Bison as a subproject [...] For this, I would need to have a
Meson build definition for Bison" is a fairly clear description of what
I want to achieve.

> On Sonntag, 20. Dezember 2020 08:09:59 CET Akim Demaille wrote:
>>> Despite many projects moving to Meson, unfortunately, I don't think that
>>> it yet supports as many niche systems as autotools, thus it may not yet
>>> be desirable for Bison to move away from autotools
>>
>> Anyway, this is very unlikely to happen.  Bison belongs to an ecosystem
>> where the Autotools are the standard.
> 
> I don't see Meson at a point already where it could be deployed with projects
> that are typically built in rather conservative environments, as it is the
> case with Bison. Right now you typically need a bleeding edge Meson version
> for being able to build more complex projects with Meson.

This may be, I haven't tried to build anything very complex with an old
version of Meson. Although, GLib is has a fairly complex configuration
and it is build with what I could call a relatively old version of Meson.

> Qemu just switched to Meson; they pull a specific Meson version in-tree as git
> submodule in the Qemu git repository. But really, that's an effort on its own.

This is not very different from having a truckload of m4 code pulled
into the project to support an autotools based build system, with the
exception that the Meson code (the build rules written in the Meson
language and the source code of Meson itself) can actually be understood
by humans :-)

Cheers,
Dan