Re: [Plplot-devel] Autoheadaches

[Rafael L. <lab...@ps...>]

* Alan W. Irwin <ir...@be...> [2003-01-27 15:07]:

> Can you give a reference for the "deprecated".  I have the impression you
> are correct, [...]

Three references:

1) When you run autoheader (from autoconf package version 2.57) on
   configure.ac with AM_CONFIG_HEADER instead of AC_CONFIG_HEADERS, you get
   the error message:

     $ autoheader
     autoheader2.50: error: AC_CONFIG_HEADERS not found in configure.ac
   
2) It is mentioned on one of the files of automake 1.7:
     
     $ fgrep AM_CONFIG_HEADER /usr/share/aclocal-1.7/header.m4
     # AM_CONFIG_HEADER is obsolete.  It has been replaced by AC_CONFIG_HEADERS.

3) In the Automake documentation:

     $ info -f /usr/share/info/automake-1.7.info-1.gz -n Optional

> [...] but when I looked for it last night I got two stories, (from info
> automake) AM_CONFIG_HEADER required and AM_CONFIG_HEADER optional.  I am
> sure I have also seen the story "deprecated", but can you remind me where?
     
Automake-1.7 still implements AM_CONFIG_HEADER for backwards compatibility.

> I think there is a bit of value in that file (isinf, for example).
> Where/how should we do the same thing without that file?

Well, I get here:

    $ fgrep ISINF acconfig.h include/plConfig.h.in
    acconfig.h:#undef HAVE_ISINF
    include/plConfig.h.in:#undef HAVE_ISINF

Actually, acconfig.h is fully contained in include/plConfig.h.in.  This is
why I think it is useless (just run diff -u acconfig.h include/plConfig.h.in
to convince yourself).

> A lot of this "dog's breakfast" is my fault. I don't understand autoconf so
> I left a lot of cruft in without much understanding of what was going on.  I
> was just thankful it worked at all.

It is also partly my fault, since I have let you play the Sorcerer's
Apprentice without much guidance.  Of course, I foolishly forgot my AM-LT
magic hat in the CVS repository and now the splinters of the broom are
popping out everywhere...

Fairy-tale analogies apart, the Autotools have evolved quite a lot since I
started the AM-LT branch in the PLplot repository.  I am quite sure that are
other obsolete constructs remaining in many places.

> Meanwhile, I need some input from Maurice and/or Geoffrey on what to do
> with the "touch" workaround. It seems that does work for Joao so I expect
> my tests (and Maurice's tests) of it tonight will also confirm that.
> Assuming that, should I overwrite the plplot-5.2.0 tarball and source rpm
> with the changed date on include/plDevs.h.in?  Remember, those files are
> going to get downloaded a lot before we can bring out 5.2.1.  Of course I
> will be informing plplot-general of the status of the SF file release (if I
> update those SF files) as well as the workaround.

I agree that a new interim release has to be done as soon as possible.  I
would be reluctant though to replace the tarball by another one with the
same name.  First, I even do not now if this is possible in the SF "Files"
interface.  Second, giving two different things the same name would only
lead to confusion.  You might set in it another VERSION string like
"5.2.0-rev1", or whatever.  On the other hand, just bumping the number to
5.2.1 with just a change in a file's date is an overkill.

-- 
Rafael