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: Ralf Wildenhues
Subject: Re: __m4_version__ and frozen files [was: O(n) patches and side effects]
Date: Tue, 26 Aug 2008 10:50:21 +0200
User-agent: Mutt/1.5.18 (2008-05-17)

* Eric Blake wrote on Fri, Aug 22, 2008 at 02:33:48PM CEST:
> According to Ralf Wildenhues on 8/22/2008 12:23 AM:
> > * 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.

That means they will also see the m4 warning every time, no?
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.

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.

Cheers,
Ralf




reply via email to

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