automake-patches
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] {maint} Document in detail some limitations of aclocal.


From: Stefano Lattarini
Subject: Re: [PATCH] {maint} Document in detail some limitations of aclocal.
Date: Fri, 5 Nov 2010 13:13:32 +0100
User-agent: KMail/1.13.3 (Linux/2.6.30-2-686; KDE/4.4.4; i686; ; )

On Friday 05 November 2010, Ralf Wildenhues wrote:
> Hello,
> 
> * Stefano Lattarini wrote on Thu, Nov 04, 2010 at 08:47:47PM CET:
> > I've gone ahead and documented this non-obvious limitation, and another
> > similar one regarding AC_DEFUN.  See the attached patch.
> > 
> > Ralf, ok to apply to maint?
> 
> There are a couple of things I don't like with the principle of this
> patch: hard-coding limitations in the testsuite, and hard-coding
> limitations and presenting them as such in the manual.  The latter makes
> the project look bad,
But lying about or not exposing the limitations makes the project looks
even worse, when such limitation are encounterd on the field.
> the other two are a maintenance hassle once and if the code is improved.
Please understand that the tests are meant to check that the examples
we give in the manual are correct and behaving as expected (which IMHO
is very important), and not that the aclocal limitations remain in
place (that would be foolish indeed!)
> We might even have to remove the section in the manual once aclocal
> is fixed (which is really bad because it means URLs to the per-node
> links to the manual will go bad).
Good objection.  Any idea how to solve or ameliorate this problem?
 
> That said, I think it is prudent to document *requirements* of aclocal
> that the user of aclocal and authors of macro files must meet.  But
> document them that way, and do it only if they can't be fixed.
You mean I should reword my documentation patch somehow?  If you have
precise suggestions, I'd be happy to follow them.
 
> I'm still not totally sure why aclocal didn't try to use traces, but one
> reason I can think of is the following: macros from unrelated
> third-party packages may otherwise interfere with each other; but also,
> macros from different versions of the same third-party package might all
> be found in the aclocal search path.  Can we please check history here
> before committing to anything?
I'll see what I can do, but my previous attempt at history-digging w.r.t.
this issue didn't go very well :-(
 
> I cannot tell without experimenting (e.g., installing lots of *-dev
> distro packages on my box) whether this is a problem now, or would be
> a problem when tracing with the Autoconf-without-aclocal language (which
> is defined by Autoconf already) or with Gary's proposed new language.
> 
> A problem to take into account is that if aclocal fails due to macro
> interaction for some user, she might not be able to do anything about it
> (because she is not root) thus making the whole installation a bit
> unusable.
If I understand correctly, Paolo's patch introducing the `ACLOCAL_PATH'
environment variable could offer a workaround for this situation, in
case it ever arises.

Regards,
   Stefano



reply via email to

[Prev in Thread] Current Thread [Next in Thread]