[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Migrating to autoconf 2.52g
From: |
Tim Van Holder |
Subject: |
Re: Migrating to autoconf 2.52g |
Date: |
04 Feb 2002 13:32:34 +0100 |
On Mon, 2002-02-04 at 12:28, John Poltorak wrote:
>
> > autoconf 2.5x provides 'autoupdate', which will try to do just that.
>
> Does autoupdate create a new configure.in?
It does an in-place update of configure.in, making a backup of the
original one as configure.in~.
> When running autoupdate I get:-
>
> + autoupdate
> autom4te.: no such file or directory: /dev/null
> autoupdate.: cannot close autom4te ...
I would guess that whatever OS/2 environment you use (EMX I guess) does
not provide emulation for /dev/null (or at least bash and/or perl
don't). Perhaps autoconf needs to detect this:
DEVNULL=/dev/null
test -f /dev/null || { test -f NUL && DEVNULL=NUL }
or something similar.
> Also I notice a directory called:-
>
> autom4te..cache
>
> in the working directory. Is this name correct? - It looks wrong...#
Looks like a bug in perl or bash, also apparent in the error messages
above; it seems that $0 has a trailing '.', leading to incorrect set up
of the directory (though it should not pose a real problem, as autoconf
will always refer to that 'unusual' path; it's only a problem if the
name is ever hard-coded).
> > Be warned though that many applications used configure.ins that relied
> > on undocumented and unsupported autoconf internals; those will often
> > break with autoconf 2.5x, and may require non-trivial rewriting.
> >
> > Basically, when confronted with an outdated configure.in, back up the
> > configure script and run a recent autoconf/autoheader (possibly in
> > tandem with a recent aclocal & automake).
> > If autoconf does not complain, things will probably be ok.
> > If it complains, try running autoupdate, and then autoconf again.
>
> Can a test to see if these functions need to be run be incorporated into
> autoconf itself so that they are run automatically when necessary?
I don't know, but I doubt it. If that were possible, I don't think we
would have needed autoupdate in the first place, as autoconf could have
handled everything directly.
- Migrating to autoconf 2.52g, John Poltorak, 2002/02/04
- Re: Migrating to autoconf 2.52g, Tim Van Holder, 2002/02/04
- Re: Migrating to autoconf 2.52g, John Poltorak, 2002/02/04
- Re: Migrating to autoconf 2.52g, Paul Eggert, 2002/02/04
- Re: Migrating to autoconf 2.52g, John Poltorak, 2002/02/04
- Re: Migrating to autoconf 2.52g, Akim Demaille, 2002/02/05
- Re: Migrating to autoconf 2.52g, John Poltorak, 2002/02/05
- Re: Migrating to autoconf 2.52g, Tim Van Holder, 2002/02/05
- Re: Migrating to autoconf 2.52g, Akim Demaille, 2002/02/05