[Top][All Lists]
[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
signature.asc
Description: This is a digitally signed message part.