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

[Patrick Steinhardt <ps@pks.im>]

On Sun, Dec 08, 2024 at 12:00:46PM +0900, Junio C Hamano wrote:
> Patrick Steinhardt <ps@pks.im> writes:
> 
> > As support for Meson is still in-flight we have to accommodate for
> > conflicts with topics in "seen". The following conflicts are being
> > addressed in this commit:
> >
> >   - ej/cat-file-remote-object-info adds t1017 and "fetch-object-info.c".
> >
> >   - ds/path-walk-1 adds t6601 as well as "path-walk.c" and
> >     "test-path-walk.c".
> >
> >   - js/libgit-rust adds "common-exit.c" and "common-init.c".
> >
> >   - ds/name-hash-tweaks adds "t/helper/test-name-hash.c".
> >
> > This is somewhat painful in the current state where Meson is not yet
> > part of the main tree, but we'll have to live with that for the time
> > being.
> >
> > I've split this commit out into a separate fixup-style commit such that
> > it is possible to test this topic both with and without "seen" merged
> > into it. You can simply revert this commit to test without "seen".
> 
> Now I had to reconstruct these "fixup-style" commits and they appear
> under ref/merge-fix/ hierarchy in my broken-out repository published
> at https://github.com/gitster/git.git/ (and no other fallback URLs;
> it might make sense to have another repository for redundancy, but
> it is an unrelated tangent).  In addition to these listed four, a
> newly added ds/backfill also needs refs/merge-fix/ds/backfill to
> adjust.

Okay.

> What I noticed while performing this exercise to place ps/build~1
> (i.e. the series without this step) immediately on top of where the
> history leading to 'seen' has a commit whose tree matches that of
> 'next' is that we need some "distributed" (read: put the burden on
> topic authors, not on the onwer of ps/build topic, and not on the
> maintainer) way to make sure various list of files in meson.build,
> t/meson.build, and t/helper/meson.build are in sync with
> corresponding list of files in the Makefile world.  It _should_ be
> automatable in theory, and to help those who develop against the
> current practice of treating Makefile as the authoritative build
> system, a Makefile target that tells them that they added a new file
> to Makefile and removed a file from t/Makefile but they forgot to
> make corresponding changes to meson.build and t/meson.build files
> would be very beneficial.  We could run that target as a part of
> "make test".
> 
> Of course, those who care about keeping CMake build up to date can
> add something similar hooked up to help others help themselves.

I have the following change queued up in a local patch series:

    # Sanity check that we are not missing any tests present in 't/'. This check
    # only runs once at configure time and is thus best-effort, only. It is
    # sufficient to catch missing test suites in our CI though.
    actual_tests = run_command(shell, '-c', 'ls t[0-9][0-9][0-9][0-9]-*.sh', check: true).stdout().strip().split('\n')
    if integration_tests != actual_tests
      missing_tests = [ ]
      foreach actual_test : actual_tests
        if actual_test not in integration_tests
          missing_tests += actual_test
        endif
      endforeach
      if missing_tests.length() > 0
        error('Missing tests:\n\n - ' + '\n - '.join(missing_tests))
      endif

      superfluous_tests = [ ]
      foreach integration_test : integration_tests
        if integration_test not in actual_tests
          superfluous_tests += integration_test
        endif
      endforeach
      if superfluous_tests.length() > 0
        error('Superfluous tests:\n\n - ' + '\n - '.join(superfluous_tests))
      endif
    endif

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 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.

Patrick