bug#19418: AC_CONFIG_FILES / stamp-h? problem
On 22 Feb 2022 12:53, Jeff Squyres (jsquyres) wrote: > I'm afraid I can't easily tell. > > It looks like I added a workaround in > https://github.com/open-mpi/ompi/commit/40dd4c5b766ff62a681692b1fa6b72a1023fc81f > on Dec 20, 2014 (the same day that I initially filed this bug report). > > Half of that workaround was removed in June of 2015 when we stopped embedding > a major component > (https://github.com/open-mpi/ompi/commit/3e1b85ceb36d952190934e041b8894db98bb38ef); > the other half persisted for several years until we changed packaging of > another major component in October of 2020 > (https://github.com/open-mpi/ompi/commit/0e9581d478a20b496c579c9510ea0f3d644a460d). > Honestly, I think that when I put in the workaround, we forgot about the > issue -- the workaround ultimately disappeared organically over time when we > made other major changes to the Open MPI code base. > > So I can't say whether the bug ultimately got fixed in subsequent versions of > Automake, whether it was fixed in Open MPI's m4 code, or whether the other > major changes in Open MPI made the issue moot. thanks, that helps. i can reproduce what you're seeing. i haven't dug deeper yet to see what's going on. $ git clone https://github.com/open-mpi/ompi $ cd ompi $ git checkout 40dd4c5b766ff62a681692b1fa6b72a1023fc81f $ WANT_AUTOCONF=2.69 WANT_AUTOMAKE=1.14 autoreconf -vfi $ ./configure $ grep ^config_headers= config.status config_headers=" opal/include/opal_config.h ompi/include/mpi.h oshmem/include/shmem.h opal/mca/hwloc/hwloc191/hwloc/include/private/autogen/config.h opal/mca/hwloc/hwloc191/hwloc/include/hwloc/autogen/config.h opal/mca/common/libfabric/libfabric/config.h" $ grep -A1 ^distclean-hdr Makefile.in distclean-hdr: -rm -f \ opal/mca/common/libfabric/libfabric/config.h \ opal/mca/common/libfabric/libfabric/stamp-h4 \ opal/mca/hwloc/hwloc191/hwloc/include/private/autogen/config.h \ opal/mca/hwloc/hwloc191/hwloc/include/private/autogen/stamp-h5 \ opal/mca/hwloc/hwloc191/hwloc/include/hwloc/autogen/config.h \ opal/mca/hwloc/hwloc191/hwloc/include/hwloc/autogen/stamp-h6 Automake 1.16 does the same thing. $ aclocal-1.16 && automake-1.16 $ grep -A1 ^distclean-hdr Makefile.in distclean-hdr: -rm -f \ opal/mca/common/libfabric/libfabric/config.h \ opal/mca/common/libfabric/libfabric/stamp-h4 \ opal/mca/hwloc/hwloc191/hwloc/include/private/autogen/config.h \ opal/mca/hwloc/hwloc191/hwloc/include/private/autogen/stamp-h5 \ opal/mca/hwloc/hwloc191/hwloc/include/hwloc/autogen/config.h \ opal/mca/hwloc/hwloc191/hwloc/include/hwloc/autogen/stamp-h6 -mike signature.asc Description: PGP signature
bug#54063: automake cannot run without generated Texinfo manual
On Sat, Feb 26, 2022 at 12:07:09AM -0500, Mike Frysinger wrote: > On 25 Feb 2022 16:06, Karl Berry wrote: > > Adding a note to the manual is fine, but what would be (much) more > > likely to actually get noticed by users is a runtime warning. What is > > the actual behavior when the basename and @setfilename don't match? > > i don't think it's possible to detect from automake, at least at `automake` > time. the point of Patrice's report is that the sources don't exist when > automake runs, so it's not possible to inspect them. trying to go further > (having automake attempt to trace partial makefile? have it generate a > check that runs on the user's system at `make` time?) feels like it's > intruding on the territory of texinfo for no real gain. I agree, especially if a @setfilename different from the file name is used on purpose to have a different output name than the base name. I just tested a mismatch between filename and @setfilename with automake. The file name is toto.texi and @setfilename my_output.info. make info works. make html fails with: make: *** No rule to make target 'toto.html', needed by 'html-am'. Stop. make my_output.html works. I do not think that this needs to be fixed in case at Texinfo we consider that @setfilename different from the file name is bad and that @setfilename more generally should be deprecated. My recommendation would be to leave unsaid for now whether automake supports or not a different file name than @setfilename for non generated texinfo manuals in case it is later considered relevant, probably based on the advice from the Texinfo crowd. -- Pat
