#546445 A revised m4sh.m4 may be ineffective

Package:
autoconf
Source:
autoconf
Submitter:
Date:
2010-08-02 23:27:05 UTC
Severity:
normal
#546445#5
Date:
2009-09-13 09:45:34 UTC
From:
To:
After the /usr/share/autoconf/m4sugar/m4sh.m4 file is modified on the
system, autoconf may still generate the old macros when an attempt is
made to generate a configure file.
#546445#10
Date:
2009-09-13 10:00:16 UTC
From:
To:
Hello Mark,

* markhobley@yahoo.co.uk wrote on Sun, Sep 13, 2009 at 11:45:34AM CEST:

You probably have to either remove or rebuild the frozen state file(s)
*.m4f, or pass -M aka. --melt to autom4te (AUTOM4TE='autom4te -M') to
ignore them.  Don't forget to pass --force to autoconf if you don't have
the autom4te.cache disabled (and it is otherwise up to date wrt. files
in the source tree).

Hope that helps.

Cheers,
Ralf
#546445#15
Date:
2009-09-13 15:40:55 UTC
From:
To:
Examining the /usr/share/autoconf/m4sugar directory, it appears that there is a frozen m4sh.m4f file.

Looking at the autoconf package, I guess that these are generated by the autoconf-2.63/lib/m4sugar/Makefile, because they are mentioned in the Makefile.am file as follows:

  nodist_m4sugarlib_DATA = version.m4 m4sugar.m4f m4sh.m4f

  ## ------------------ ##
  ## The frozen files. ##
  ## ------------------ ##

  m4sugar.m4f: $(m4sugar_m4f_dependencies)
  m4sh.m4f: $(m4sh_m4f_dependencies)
  include ../freeze.mk

Deleting /usr/share/autoconf/m4sugar/m4sh.m4f causes the updated m4sh.m4 to take effect.

It would be better for frozen files to be placed in /var/cache/autoconf and then make used to rebuild them in the event that the m4 sources in /usr/share/autoconf become newer.
#546445#20
Date:
2009-09-13 16:19:24 UTC
From:
To:
BTW, are you fixing a bug in that file?  Would you be so nice as to
share the patch, preferably by sending it upstream?

Thanks,
Ralf
#546445#25
Date:
2009-09-13 18:07:45 UTC
From:
To:
markhobley@yahoo.co.uk writes:

Why are you modifying /usr/share/autoconf/m4sugar/m4sh.m4?  Local
changes to these .m4 files are not anticipated in the packaging
(and that's why it doesn't work).
#546445#30
Date:
2010-08-02 20:21:16 UTC
From:
To:
Hi Mark.

In September 2009, you reported:

    After the /usr/share/autoconf/m4sugar/m4sh.m4 file is
    modified on the system, autoconf may still generate the old
    macros when an attempt is made to generate a configure file.

Ralf Wildenhues <Ralf.Wildenhues@gmx.de> replied that you need to
re-freeze the .m4 file.

I followed up with a question:

    Why are you modifying /usr/share/autoconf/m4sugar/m4sh.m4?
    Local changes to these .m4 files are not anticipated in the
    packaging (and that's why it doesn't work).

I haven't seen a response yet.  Do you still believe that this is
a bug?  If you do, can you explain.  If you don't, please let me
know so that I can close the bug.

Thanks,

Ben.
#546445#35
Date:
2010-08-02 23:23:34 UTC
From:
To:
Forwarding information that failed to be CC'd to the bug report.

--- On Mon, 2/8/10, Ben Pfaff <blp@cs.stanford.edu> wrote:

It doesn't work properly on my ash shell, (there are some constructs that autoconf uses, that are not considered), and I have problems sharing scripts between machines, because autoconf makes decisions based on the test machine, which do not apply to the target.

Really, this is a bad design. If the sources are newer than the frozen files or the cache, then the frozen files or cache should be updated. (We could use make here.)

I have forked this package, and I am making appropriate modifications to the fork. I would just forward the bug information upstream, then close the bug. (The problem only affects programs that are build from source, and Debian does not do this.)

Cheers,

Mark.



-------------------- End of forwarded message --------------------