From: Mike Frysinger <[email protected]>
Newer versions of autotools have started warning when using the old
configure.in name.
Signed-off-by: Mike Frysinger <[email protected]>
---
configure.in => configure.ac | 0
1 file changed, 0 insertions(+), 0 deletions(-)
rename configure.in => configure.ac (100%)
diff --git a/configure.in b/configure.ac
similarity index 100%
rename from configure.in
rename to configure.ac
--
2.4.1
On Mon, May 25, 2015 at 05:32:32AM -0400, Mike Frysinger wrote:
> From: Mike Frysinger <[email protected]>
>
> Newer versions of autotools have started warning when using the old
> configure.in name.
>
> Signed-off-by: Mike Frysinger <[email protected]>
Note that I ship a version of configure (and keep one checked in to
git) because I do not trust the autoconf maintainers' ability to
maintain backwards compatibility, having gotten badly burned in the
past. I am currently using autoconf 2.69, and people who try to rerun
autoconf on some other version of autoconf are venturing into
unsupported territory. It may work; it may screw up in amazing ways.
Some autoconf macro may silently assume that some feature is present
when it is not, or vice versa.
And if it breaks, you get to keep both pieces. :-)
- Ted
On 08 Jun 2015 10:59, Theodore Ts'o wrote:
> On Mon, May 25, 2015 at 05:32:32AM -0400, Mike Frysinger wrote:
> > Newer versions of autotools have started warning when using the old
> > configure.in name.
>
> Note that I ship a version of configure (and keep one checked in to
> git) because I do not trust the autoconf maintainers' ability to
> maintain backwards compatibility, having gotten badly burned in the
> past. I am currently using autoconf 2.69, and people who try to rerun
> autoconf on some other version of autoconf are venturing into
> unsupported territory. It may work; it may screw up in amazing ways.
> Some autoconf macro may silently assume that some feature is present
> when it is not, or vice versa.
>
> And if it breaks, you get to keep both pieces. :-)
that's fine, but it doesn't really matter to this patch -- it should be
configure.ac and not configure.in. the version of autoconf you're using
certainly supports the newer name.
-mike
On Mon, Jun 08, 2015 at 11:56:06AM -0400, Mike Frysinger wrote:
> On 08 Jun 2015 10:59, Theodore Ts'o wrote:
> > On Mon, May 25, 2015 at 05:32:32AM -0400, Mike Frysinger wrote:
> > > Newer versions of autotools have started warning when using the old
> > > configure.in name.
> >
> > Note that I ship a version of configure (and keep one checked in to
> > git) because I do not trust the autoconf maintainers' ability to
> > maintain backwards compatibility, having gotten badly burned in the
> > past. I am currently using autoconf 2.69, and people who try to rerun
> > autoconf on some other version of autoconf are venturing into
> > unsupported territory. It may work; it may screw up in amazing ways.
> > Some autoconf macro may silently assume that some feature is present
> > when it is not, or vice versa.
> >
> > And if it breaks, you get to keep both pieces. :-)
>
> that's fine, but it doesn't really matter to this patch -- it should be
> configure.ac and not configure.in. the version of autoconf you're using
> certainly supports the newer name.
This patch breaks the automatic rebuild of configure if the
configure.ac/configure.in file is modified. I've fixed it up by
adding the necessary change to MCONFIG.in.
- Ted