Re: [RFC] add regenerate Makefile target
On Tue, Mar 19, 2024 at 2:10 PM Tom Tromey wrote: > > > not sure if the current autoregen.py is in sync with that? > > I'm curious why "autoreconf -f" is insufficient. > It seems to me that this should work. `autoreconf -f` works fine in individual subdirectories, the problem is that the top-level configure.ac doesn't use the AC_CONFIG_SUBDIRS macro to specify its subdirectories, but rather uses its own hand-rolled method of specifying subdirectories that autoreconf doesn't know about. This means that autoreconf won't automatically recurse into all the necessary subdirectories by itself automatically, and instead has to be run manually in each subdirectory separately. Also the various subdirectories are inconsistent about whether they have a rule for running it (autoreconf) from the Makefile or not, which usually comes down to whether the subdirectory uses automake for its Makefile or not (the top-level Makefile doesn't; it uses its own weird autogen-based regeneration method instead, which means that it misses out on all the built-in rules that automake would implicitly generate, including ones related to build system regeneration). > > > Also... I discovered the existence of an automake rule: > > am--refresh which IIUC is intended to automake the update of Makefile > > and its dependencies. > > Don't use that rule directly. It's an implementation detail and > shouldn't be relied on. > > thanks, > Tom
Re: [RFC] add regenerate Makefile target
On 3/18/24 13:28, Christophe Lyon via Gdb wrote: > I'm not up-to-date with gdb's policy about patches: are they supposed > to be posted with or without the regenerated parts included? > IIUC they are not included in patch submissions for binutils and gcc, > which makes the pre-commit CI miss some patches. We post the patches with the regenerated parts. Simon
Re: [RFC] add regenerate Makefile target
On 3/18/24 13:25, Christophe Lyon wrote: > Well the rule to regenerate Makefile.in (eg in in opcodes/) is a bit > more complex > than just calling automake. IIUC it calls automake --foreign it any of > *.m4 file from $(am__configure_deps) that is newer than Makefile.in > (with an early exit in the loop), does nothing if Makefile.am or > doc/local.mk are newer than Makefile.in, and then calls 'automake > --foreign Makefile' The rules looks complex because they've been generated by automake, this Makefile.in is not written by hand. And I guess automake has put `--foreign` there because foreign is used in Makefile.am: AUTOMAKE_OPTIONS = foreign no-dist But a simple call so `automake -f` (or `autoreconf -f`) just works, as automake picks up the foreign option from AUTOMAKE_OPTIONS, so a human or an external script who wants to regenerate things would probably just use that. > The bot I want to put in place would regenerate things as they are > supposed to be, then build and run the testsuite to make sure that > what is supposed to be committed would work (if the committer > regenerates everything correctly) For your job, would it be fine to just force-regenerate everything and ignore timestamps (just like the buildbot's autoregen job wants to do)? It would waste a few cycles, but it would be much simpler. Simon
