bug-automake
[Top][All Lists]
Advanced

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

Re: aclocal directory not found error


From: Mike Frysinger
Subject: Re: aclocal directory not found error
Date: Thu, 29 Jul 2010 02:26:10 -0400
User-agent: KMail/1.13.1 (Linux/2.6.34; KDE/4.4.5; x86_64; ; )

On Thursday, July 29, 2010 02:07:35 Ralf Wildenhues wrote:
> * Mike Frysinger wrote on Thu, Jul 29, 2010 at 07:52:41AM CEST:
> > On Thursday, July 29, 2010 01:40:24 Ralf Wildenhues wrote:
> > > * Behdad Esfahbod wrote on Thu, Jul 29, 2010 at 03:20:37AM CEST:
> > > > So this tiny issue has been bugging me for years.  Thought I report.
> > > > Can you please make aclocal silently ignore include directories that
> > > > do not exist?  It bothers me that on a new system when I set my env
> > > > vars to have a complete tree in my ~/.local, every directory gets
> > > > created on demand except for share/aclocal.
> > > 
> > > Yes, I accept a patch that does that for absolute paths, if it includes
> > > a test case.  Let's see if someone beats me to it.  ;-)
> > 
> > but the more common case of like `m4 -I m4` would still fail ?  i guess
> > people could work around it by using code like `m4 -I $PWD/m4` ...
> 
> Isn't the non-existence of an in-tree directory an error usually though?
> (Honest question, if there are good setups that can't provide this we
> should reconsider.)

one example where ive hit this is with projects using git:
 - initial clone is done
 - local libtool is configured with AC_CONFIG_MACRO_DIR(m4) like it suggests
 - m4/ only contains generated files, and those arent in git, and git doesnt 
keep track of empty dirs. so no m4/ exists at this point in time
 - Makefile.am has ACLOCAL_FLAGS = -I m4 as it should
 - initial `autoreconf` aborts due to m4/ not existing because libtoolize 
wasnt run early enough to populate m4/ with files

so i could do `mkdir m4` before the `autoreconf` and forget about it, but the 
issue comes right back as soon as i do something like `git clean -x -d` (which 
i frequently do).

> Can we find a compromise that at least has a chance for typo detection?

i'm ok with a warning about the dir not existing (i.e. errno == ENOENT) and so 
it'd skip it, but the fatal abort is obnoxious.  if it were some other reason 
(e.g. errno == EPERM), then i'm also ok with it aborting.  this is what many 
other common projects such as gcc do with unreadable include paths.

i think these conditions would satisfy everyone ?
-mike

Attachment: signature.asc
Description: This is a digitally signed message part.


reply via email to

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