On Thursday 17 March 2011, Maynard Johnson wrote: > On 03/17/2011 5:17 AM, Stefano Lattarini wrote: > > Well, you could always resort to adding proper `-I' option to > > you aclocal calls. Also, in the next automake release, aclocal > > will probably support a new 'ACLOCAL_PATH' environment variable > > that would help solving this kind of problems > > > Except this happens when building a 3rd party package. Yes, I have the > source for that package, and, in fact, the first fix I did was to update > its autogen.sh (where aclocal is called) to add '-I /usr/share/aclocal'. > But that didn't seem like the right way to go either for the general case > (i.e., I don't think that's an appropriate fix to contribute back to the > package maintainer). > I'd expect a properly written autogen.sh script to honor the ACLOCAL environment variable when calling aclocal; if that is the case, you can resort to: $ ACLOCAL='aclocal -I /usr/share/aclocal' ./autogen.sh without having to modify any file. If OTOH the autogen.sh script doesn't honor the ACLOCAL environment variable, IMHO it's broken, and contributing a patch about this back to the package maintainer would be the right thing to do (again IMHO).
BTW, this is an example of where the yet-to-be-implemented 'ACLOCAL_PATH' would be really useful: instead of having to hack the autogen.sh as above, you could simply do: ACLOCAL_PATH='/usr/share/aclocal' ./autogen.sh which would work also if autogen doesn't honor the ACLOCAL environment variable. > I think the best I can do is to suggest an FAQ on that package's web > site that documents the error and the solution. > That could go in the FAQ section of the Automake manual: <http://www.gnu.org/software/automake/manual/html_node/FAQ.html> I might attempt a patch, but not soonish. You are free to beat me if you want to give a try ;-) Thanks, Stefano
