Bruno Haible wrote, quoting me: >> Having segregated the m4 files, you then use aclocal to reassemble >> them into aclocal.m4. > > You will notice that after running 'aclocal -I m4', the aclocal.m4 > file contains symbolic references to the various *.m4 files, not > their contents. (Assuming you are using the automake-1.9.x tools.)
I don't use *any* version of automake, (and I fervently hope that Werner will never take groff down this route). The current problem with aclocal is that it is a tool distributed with automake, yet its value seems more applicable to use with autoconf. >> Current wisdom from the autoconf mailing >> list would suggest that aclocal, as a configuration tool, should >> be considered as deprecated. > > If it's deprecated, then what is its replacement? For me it is, and always has been vim :-) OTOH, where it is known that *all* files in a specified m4 subdiriectory are to be subsumed into aclocal.m4, a combination of ls, or even echo, with either sed or awk should suffice. > As far as I know, there is agreement that future versions of autoconf > and automake could get away without a tool that just collects a list > of filenames and creates a file from it. But the latest releases of > autoconf and automake still need 'aclocal'. > >> Is it really appropriate to start >> using it within groff's build system, at this late point in time? > > groff's current build system doesn't yet use automake. Do you know > whether the replacement of 'aclocal' will work with just 'autoconf'? > Or will it rely on both autoconf and automake? I don't know. I don't either. It just seems strange that an autoconf managed project, which does not use automake, should rely on a tool which is distributed only with automake. Regards, Keith. _______________________________________________ Groff mailing list [email protected] http://lists.gnu.org/mailman/listinfo/groff
