Re: [PATCH v11 25/26] meson: fix conflicts with in-flight topics

From: Patrick Steinhardt <ps@pks.im>
Date: Dec 10, 2024, 11:20 UTC
Message-ID: <Z1gj4M-qHQ2Qcq5a@pks.im>
In-Reply-To: <xmqqplm1nv7g.fsf@gitster.g>

On Mon, Dec 09, 2024 at 04:58:59PM +0900, Junio C Hamano wrote:

Show 33 quoted lines

> Patrick Steinhardt <ps@pks.im> writes:
> 
> > I have the following change queued up in a local patch series:
> > ...
> > What it does is to verify that test suites wired up in Meson are
> > up-to-date, and if they aren't `meson setup` will fail and print all
> > missing or extraneous test suites. For code it's a bit harder to do as a
> > lot of it only compiles conditionally, so I don't have a solution for
> > that yet.
> 
> It would certaionly help those who build work "meson" to remind
> themselves that they need to make matching changes to Makefile world
> when they update their meson.build files.
> 
> > It also doesn't execute as part of `make test` -- if we want that I'd
> > have to implement it via a separate shell script instead. Which isn't
> > too bad, we'll simply have to agree on a direction. But the logic will
> > execute as part of CI so that any discrepancies will be flagged.
> 
> And catching a breakage as part of CI is a good first step
> nevertheless.
> 
> Having said all that, with a longer term evolution of the build
> systems in mind:
> 
>  - Currently, anybody who is working on our codebase is expected to
>    make "make all doc test" succeed before even running format-patch
>    and/or send-email.  But unless you are testing with ps/build
>    topic, you won't be checking "meson test".  The same is likely be
>    true for CMake (I am not encouraging folks to send a change that
>    is OK only for "make" and deliberatly breaks "meson" and "cmake";
>    but for those who are used to build with "make", having to _also_
>    check with "meson" and "cmake" is additional barriers.

Fair.

Show 6 quoted lines

>  - The ideal world, at least from the point of view of those
>    advocate ps/build topic, should be that "meson" is treated at
>    least as another build system with equal footing as "make".  With
>    even longer timeframe, the effort may even aim to supersede and
>    deprecate "make", but before that happens, it has to at least
>    become build system with equal importance.

Agreed, feature parity is a necessary requirement and I'll of course continue to iterate on it once Meson has landed. We might get away with removing the autoconf framework without feature parity as users can still use "make" without it, and because it's seldomly used and broken. But replacing "make", if it happens at all, is a much larger undertaking that will require many releases.

I'll also align with Dscho to figure out what to do with CMake.

Show 21 quoted lines

>  - In the longer timeframe where many more folks work with "meson"
>    than "make", check implemented on the "meson" side to make sure
>    that "make" world will not left rotting would be helpful before
>    we finally kill off "make" support (if that is what we are aiming
>    for).  But until then, I think the pay off would be larger if we
>    helped "make" population to avoid leaving "meson" and "cmake"
>    builds out of sync when they update Makefile.
> 
> And that is why I suggested "make test" as that is currently what is
> run by everybody.  It is like &&-check that helps individual developers
> with their test before even submitting their changes.
> 
> I am unlikely to run the check locally before pushing them out,
> simply because meson build is not yet part of my everyday workflow,
> but even after I made it part of my workflow to check, in a sense,
> it it too late.  Once we adopt ps/build~1 as a part of our official
> world, if a developer, who builds on top of the 'master' in the not
> so distant future, does not pay attention when they touch Makefile
> without making matching changes to meson.build files, I'd want to be
> able to scold them for not running "make test"; otherwise the
> process will not scale.

Fair.

Show 7 quoted lines

> I also had to wonder if we can share the common list of files and
> have both make and meson worlds include them from the same source,
> but if the eventual goal is to migrate into a single system, it is
> not all that great an idea.  After giving up on one of the systems,
> we would not want to keep a system where we keep a list of source
> files in a separate file (possibly in a separate syntax), which is
> not how either world would normally work.

That would be great indeed, but it's somewhat incompatible with how higher-level build systems work. We do it in CMake by parsing our Makefile and extracting source files, but the problem is that this only happens at configuration time. So the set of source files would not be updated properly when your Makefile changes. An alternative would be to use globbing, but that is not recommended, either. Quoting CMake docs:

    We do not recommend using GLOB to collect a list of source files
    from your source tree. If no CMakeLists.txt file changes when a
    source is added or removed then the generated build system cannot
    know when to ask CMake to regenerate. The CONFIGURE_DEPENDS flag may
    not work reliably on all generators, or if a new generator is added
    in the future that cannot support it, projects using it will be
    stuck. Even if CONFIGURE_DEPENDS works reliably, there is still a
    cost to perform the check on every rebuild.

The same is true for Meson:

    Meson does not support this syntax and the reason for this is
    simple. This cannot be made both reliable and fast. By reliable we
    mean that if the user adds a new source file to the subdirectory,
    Meson should detect that and make it part of the build
    automatically.

    One of the main requirements of Meson is that it must be fast. This
    means that a no-op build in a tree of 10 000 source files must take
    no more than a fraction of a second. This is only possible because
    Meson knows the exact list of files to check. If any target is
    specified as a wildcard glob, this is no longer possible. Meson
    would need to re-evaluate the glob every time and compare the list
    of files produced against the previous list. This means inspecting
    the entire source tree (because the glob pattern could be
    src/\*/\*/\*/\*.cpp or something like that). This is impossible to
    do efficiently.

We could of course eventually reverse the logic and have Makefiles parse files from Meson. But as mentioned already, the biggest issue is that we have lots of source files that get compiled conditionally, and properly parsing these would be non-trivial.

I guess we'll see over time how much of a problem it is to keep build systems in sync. Proper tooling is a first step to make things a bit less tedious, but if this still proves to be too painful I'll have a look for how to further automate things.

Patrick