autoconf-patches
[Top][All Lists]
Advanced

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

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


From: Eric Blake
Subject: __m4_version__ and frozen files [was: O(n) patches and side effects]
Date: Fri, 22 Aug 2008 06:33:48 -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

[adding m4-discuss]

According to Ralf Wildenhues on 8/22/2008 12:23 AM:
> Hi Eric,
> 
> * Eric Blake wrote on Fri, Aug 22, 2008 at 06:23:38AM CEST:
>> Meanwhile, I discovered a slight flaw in m4_init that I'm not 
>> sure how to fix yet - if you freeze m4sugar.m4f with m4 1.6, but then reload 
>> it 
>> with 1.4.x, then m4_init sees the __m4_version__ from the frozen file and 
>> proceeds to use the quadratic methods, rather than realizing that foreach.m4 
>> is 
>> needed.  On the other hand, why would people build with newer m4 then 
>> downgrade 
>> to an older m4?  So I'm not even sure whether this scenario needs to work.
> 
> I do this kind of stuff, for testing.  Other people might decide to back
> down, when an early 1.6 stable release turns out to have that fatally
> ugly flaw that makes their software stop working.  So, it's not exactly
> common, and not a show-stopper if it doesn't work, but making going back
> easy is nice.  If the scenario doesn't work at all, a note in m4-1.6/NEWS
> would be nice.

Other thoughts: should __m4_version__ be a proper builtin rather than a
text string?  m4 1.4.5 and later ignore unknown builtins, but only as long
as you don't try to invoke them.  Unfortunately, those unknown builtins
still pass ifdef tests, so that doesn't help m4_init's current usage
pattern; and using m4_defn([__m4_version__]) would warn in that case.
1.4.x behavior is fixed, but starting with 1.6, should reloading frozen
files take any notice of which version is being reloaded, and alter the
definition of __m4_version__ if the running m4 is newer/older than the m4
that created the frozen file?

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.

- --
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

iEYEARECAAYFAkiusiwACgkQ84KuGfSFAYBpQwCfTPHE7ldZ9IQdKU8Z2sVsTYvW
aRgAn1r+DnlUZ3Hg6csFjKvIrIna0G2K
=CGwM
-----END PGP SIGNATURE-----




reply via email to

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