severity 13624 minor tags 13624 + moreinfo thanks On 02/04/2013 01:14 AM, Taylan Ulrich B. wrote: > Good day, > > The ACLOCAL_PATH environment-variable might benefit from better > documentation. > This is a little vague. What do you mean by "better documentation"? Do you find specific passages unclear? Is the documentation too short, or too long-winded?
In any case, the best way towards a fix would probably be for you to offer a patch with your proposed improvements. I've found out that active users of a feature are often better at documenting or explaining it than developers of the same features are (and both are usually better than I am :-) > A mention in the short man-page would probably be best, > Consider that the man pages for aclocal and automake are just slightly tweaked versions of the respective '--help' output of those programs, and as such they should remain very short. But if you want to attempt a patch to enhance the help screen to also tell about ACLOCAL_PATH, and do so keeping it short ans sweet, you might easily sway my decision ;-) > since setting it is needed to get aclocal to work at all after > installing it in a non-standard path like ~/usr. > This is not true; the only issue is that *third-party* m4 files (those not provided by Automake itself) that are installed in the aclocal directory of another aclocal installation (say, in '/usr/share/aclocal') are not available by default to the new aclocal installation. > Also, should --print-ac-dir respect it? > No, because it just prints the *hard-coded* default directory where aclocal looks for third-party macros: <http://www.gnu.org/software/automake/manual/automake.html#index-g_t_002d_002dprint_002dac_002ddir-273> > Currently it doesn't. > And this is by design. Do you have a real use-case for wanting '--print-ac-dir' to print all the directories that would be searched by aclocal? If yes, we might think of a new option for that (it should pretty easy to implement). Thanks, Stefano
