On Sun, Dec 08, 2024 at 12:00:46PM +0900, Junio C Hamano wrote: > Patrick Steinhardt <ps@xxxxxx> 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
