https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116400
--- Comment #11 from Jonathan Wakely <redi at gcc dot gnu.org> --- (In reply to Francois-Xavier Coudert from comment #10) > I'd rather have a script like libgfortran/regenerate.sh, that calls m4 and > updates the tree. Then maintainers know that, if they changed any m4 file, > they need to regenerate. (It does not happen that often.) Yes! As I've pointed out before, --enable-maintainer-mode affects the entire build tree, not just the fortran sub-dirs. That means it's fragile and prone to problems that are caused by changes outside the fortran sub-dirs (because nobody except the fortran devs ever uses maintainer-mode). This then leads to fortran devs being blocked waiting for changes from non-fortran devs, which are unnecessary dependencies and cause frustration. It would be much more reliable to use the common approach for regenerating Makefile.in, configure etc (i.e. autoreconf like the rest of the GCC tree) and then use a separate libgfortran-specific solution for regenerating source files using m4. Having that regeneration happen as a side effect of building with --enable-maintainer-mode **and being unable to do it any other way** is a fragile hack. It would probably be fine for maintainer mode to *also* run that script when appropriate, but there should be some standalone script (or makefile target, or whatever) to perform that regeneration step independent of maintainer mode. For example, libstdc++-v3/include/bits/version.h needs to be regenerated when libstdc++-v3/include/bits/version.def is changed. You can either do that manually by running 'autogen version.def' in the source dir, or running 'make -C include update-version' in the build dir. When maintainer mode is enabled, version.h will be automatically regenerated if it's older than version.def. But since none of the libstdc++ devs use maintainer-mode, we just regenerate it manually as needed. If it wasn't just a single autogen command then we'd provide a script to do whatever steps were needed.
