[RFC PATCH] build: add meson build system

[Tomi Ollila]

On Sun, Jan 12 2020, Jani Nikula wrote:

> On Sun, 12 Jan 2020, David Bremner <david at tethera.net> wrote:
>> Jani Nikula <jani at nikula.org> writes:
>>
>>> This is a draft patch adding basic configure, build and test support
>>> for the binaries. Everything else is left out for now. It would be a
>>> considerable amount of work to convert everything, and I don't expect
>>> it to be possible in one go anyway. If there's interest in adding
>>> meson support, it would have to happen gradually, side-by-side with
>>> the current system, with a reasonably long transition period. But
>>> there's no point in going beyond the patch at hand if folks decide the
>>> focus should remain on the current system.
>>
>> Personally I think the idea is worth pursuing, but I admit I don't have
>> much experience with meson/ninja.  How much churn can we expect from
>> meson changes? It seems there is something like one meson point release
>> per month.
>
> I build projects with meson regularly, but I don't develop the build
> files on a regular basis. So take this with a grain of salt. But I think
> overall the experience has been pleasant. They do keep adding features
> all the time, but AFAIK the version currently in e.g. Debian stable is
> usable, and the new features don't break existing stuff.
>
> If you want to hold back to an older version, you might have to put more
> effort to things that are easier in newer versions - but the solution
> should work in all versions. Any churn would be caused by taking
> advantage of the new features.
>
>> Are the tests supposed to be working fully in this version? When I run
>>
>> % meson && cd build && ninja && ninja test
>>
>> I get failures in T010, T351, T356, T357, T391, T395, and T710.  At a
>> glance it looks like mainly out-of-tree related problems to finding
>> e.g. json_check_nodes.py and message-id-parse. It also looks like a few
>> variables like TEST_RUBY and NOTMUCH_HAVE_PYTHON3_CFFI are not being
>> set.
>
> I get those failures too, as I haven't bothered with debugging in more
> detail yet. I just brought this to a point that mostly works.
>
> If we decide we can start merging meson support, it's going to be
> experimental and not fully featured initially. I think we'd have to
> decide what's "good enough". Obviously I think the tests must all pass,
> either by fixing the issues or gracefully disabling features. For
> example, I don't currently build any of notmuch-emacs or documentation -
> they will require custom build rules, while all the C and C++ work out
> of the box.
>
> I think mostly meson support can be added in parallel to the existing
> system. Some things might have to be fixed for both, e.g. meson only
> works with out-of-tree builds. The annoying part will be the transition
> period, where you have to maintain both. And if we decide we'll want
> both ad infinitum, it'll be an annoyance ad infinitum... ;)

I think there are 2 options

1) make meson build system good enough we can just drop the old system
   (I can test how well this works on older systems out of the box --
    and on my current containerized centos 6 notmuch build system =D)

2) an experimental version is merged, but no-one sending patches is
   expected to test that it works and someone(tm) can then update it
   while evolving it to fully supported system... perhaps the version
   tarballs would not have these so users there don't get confused

3) (the off-by-one-option) everyone is expected to keep the experimental
   version working while sending patches -- which would jut be painful :/


I personally like (1), but if it is not good enough (2) -- my reason for
having (at least) 2 is that it provides me better opportunity to learn
meson system =D
  
> BR,
> Jani.

Tomi