autoconf-patches
[Top][All Lists]
Advanced

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

Re: __m4_version__ and frozen files [was: O(n) patches and side effects]


From: Eric Blake
Subject: Re: __m4_version__ and frozen files [was: O(n) patches and side effects]
Date: Tue, 26 Aug 2008 06:47:34 -0600
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.16) Gecko/20080708 Thunderbird/2.0.0.16 Mnenhy/0.7.5.666

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

According to Ralf Wildenhues on 8/26/2008 2:50 AM:
>>
>> Or maybe its worth teaching autom4te about exit status 63 when trying to
>> reload frozen files.  By making m4 1.6 use V2 format, m4 1.4.6 and newer
>> will exit with version mismatch (m4 1.4.5 users are out of luck); autom4te
>> should then fall back to using the file unfrozen before declaring complete
>> failure.  This means that a user that installs autoconf with newer m4,
>> then downgrades m4, will not be quite as efficient because they no longer
>> get the frozen file speedups (not to mention extra forks of m4), but it
>> should at least allow them to proceed.
> 
> That means they will also see the m4 warning every time, no?

Not necessarily - autom4te captures stderr during the m4 run; it is only
after the run that the errors are replayed to the user.  So autom4te could
silently discard all errors on exit status 63, and try again in --melt mode.

> Might be good to have to let them know that their setup is
> suboptimal, but if their hands are bound (to their distro's
> or their admin's will), then that might not be so nice.

I'm not sure which way to go here.  Mentioning that m4 is older than the
installed m4 at the time autoconf was installed on every run might be
noisy, but still a good clue to update.

> 
> Thinking about this, and considering that a downgrade is probably
> unlikely, I think it isn't much of a problem at all if the
> downgraded user uses the quadratic algorithms.  After all, all
> configure.ac setups we know about don't see a noticeable performance
> change anyway.

It's not quite like that.  If m4 1.6 uses frozen file V2, then m4 1.4.x
will not be able to use that frozen file at all.  And if it sticks with
V1, then today's patch to use m4_debugmode([+d]) will evoke a warning
about the use of an unknown debugmode flag, which also breaks m4.  So with
no changes, downgrading to m4 1.4.x will flat out fail, rather than fall
back to quadratic algorithms.

I'm looking at autom4te.in; right now it calls xsystem (which aborts if m4
fails, even if the failure is status 63).  I see two possible options.
One is to enhance xsystem to take an optional parameter of the fallback
command to execute if the first command fails with version mismatch (and
here, it would be a matter of always computing the command-line for --melt
as the fallback command); this only helps if m4 1.6 uses V2 frozen files
so that m4 1.4.x exits with status 63.  The other option is to look at the
@m4_builtin map, and if __m4_version__ is not present, add an explicit
option -U__m4_version__ to the list handed to xsystem, which will nuke
whatever value __m4_version__ had within the frozen file (and m4 1.4.x
will have the benefit of using linear algorithms).  That sounds simpler to
implement, but it only helps if m4 1.6 uses V1 frozen files.  But since it
is simpler, I'll implement it first, and if I can't figure out how to
rework xsystem today, then I'll go ahead with the release of 2.63 with
just that patch (the release of m4 1.6 is still up in the air as to
whether it should use V1 or V2 frozen files).

- --
Don't work too hard, make some time for fun as well!

Eric Blake             address@hidden
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkiz+2YACgkQ84KuGfSFAYD9jwCfQeWqhOaj3PVb+NW3qJNopx6R
OIYAn1IiFpl/8W1yz1ghZohet4AF5Utq
=1lp3
-----END PGP SIGNATURE-----




reply via email to

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