Hi Ralf, On Tue, Aug 11, 2009 at 4:40 PM, Ralf Wildenhues<[email protected]> wrote: > * Sam Steingold wrote on Tue, Aug 04, 2009 at 06:06:03PM CEST: >> automake requires aclocal.m4 to be present in the current directory. >> this is not the case for me, I have one master aclocal.m4 and a few >> subprojects, each with its own Makefile.am and configure.in. >> this means that for automake to run, I have to create a temp symlynk for >> aclocal.m4 and then the generated Makefile requires the symlink to be present >> (otherwise it calls automake which fails because aclocal.m4 is not in the >> current directory). > > Hmm, that's not so easy, because aclocal, trying to optimize, puts only > those macros from the Automake package into the aclocal.m4 file which > are used for the Automake support in the current package. So if one of > your subprojects needs another macro, it couldn't detect that, and your > configure script could not be generated correctly.
I know. the aclocal.m4 is generated based on the concatenation of all the subproject configure.in. > OTOH, aclocal.m4 files are typically not large any more if the macro > files they reference are in-tree (then they mostly contain a list of > m4_include()s for those files), so having a few of them around doesn't > hurt that much. mine is almost 20k lines. >> Would it be possible to add a command line option to automake to specify the >> location of the aclocal.m4? > > Hmm, even having that (without the ability to share generated aclocal.m4 > files between packages) could open at least a small can of worms, as a > few of the tools rely on the exact location of this file. Haven't > checked in detail yet, though. I don't think it is wise for any tool to "rely on the exact location of" any file. moreover, in addition to the --aclocal command line argument, I would like the environment variable $ACLOCAL_M4 to be respected. -- Sam Steingold <http://sds.podval.org>
