On Mon, Dec 09, 2024 at 04:58:59PM +0900, Junio C Hamano wrote:
> Patrick Steinhardt <ps@xxxxxx> 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.
> - 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.
> - 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.
> 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
