Re: [Plplot-devel] Aspirin for autoheadache

[Alan W. I. <ir...@be...>]

On Thu, 30 Jan 2003, Alan W. Irwin wrote:

> I think we have clearly run up against a bug in autoconf since autoheader is
> not supposed to be run on those files at all.  (It is only supposed to be
> used to generate files from scratch such as config.h.in, not modify existing
> files, and besides these are the second and third files in the list for
> AC_CONFIG_HEADERS, and the documentation says autoheader should only be
> invoked for the first file.)
>
> Rafael, in your first post you had a suggestion for supressing autoheader
> altogether.

I have just (tentatively) committed that workaround as a basis for
discussion and testing.  (Also, I have moved AC_CONFIG_HEADERS right after
AC_INIT as the documentation says to do, but it made no difference, and the
bug still exists for that case.)

What the redefinition means is that autoheader is turned into the command:
"echo autoheader ignored" throughout all Makefiles.  So effectively
autoheader can never be invoked from the make command even in those cases
(e.g., config.h.in) where it *should* be invoked (i.e., whenever
configure.ac is changed, config.h.in should be regenerated, and now that
won't happen automatically using the make command.  However, you can arrange
it to happen from ./bootstrap.sh, and I think that is good enough.
Actually I am not sure if rm -f is cross-platform so I touch; rm; touch
to get a fresh zero-length file which is then replaced by autoheader run
from ./bootstrap.sh.)

Anyhow, I have also committed the ./bootstrap.sh change as a basis for
further discussion and testing.

Note, in my tests so far configure outputs the message that config.h is
unchanged (with the same old date).  There are similar messages for
include/plConfig.h and include/plDevs.h.  So I think these bug workarounds
are doing the right thing with respect to making gratuitous date changes to
header files if none of the symbols have been changed.

However, the gratuitous touching of include/plConfig.h.in and
include/plDevs.h.in is a bit of a pain with regard to the CVS messages about
what files have been recently updated when you are trying to commit
something.  But I can live with that until the autoconf/autoheader bug is
fixed.  (In the back of my mind I can visualize thousands of projects using
this "echo autoheader ignored" workaround rather than putting on the
pressure to get the stupid bug fixed.) But I hasten to add I also am
unwilling to submit a bug report at this time because I simply don't have
the time.  To do it right you would make a really simple fake "hello world"
project with a couple of defines and then see whether autoheader is invoked
appropriately or not.

Anyhow, I think we have a tentative solution (thanks mostly to Rafael).
Of course it will require extensive testing.

Furthermore, there are still more problems to solve.  For example, I noticed
a warning message from configure:

checking for itcl.h... /usr/include/tcl8.3/itcl-private/generic/itcl.h
checking itclDecls.h usability... no
checking itclDecls.h presence... yes
configure: WARNING: itclDecls.h: present but cannot be compiled
configure: WARNING: itclDecls.h: check for missing prerequisite headers?
configure: WARNING: itclDecls.h: proceeding with the preprocessor's result
configure: WARNING:     ## ------------------------------------ ##
configure: WARNING:     ## Report this to bug...@gn.... ##
configure: WARNING:     ## ------------------------------------ ##
checking for itclDecls.h... yes

Something seems really screwed up there.  Maurice, since you worked on that
aspect of the configuration before, can you sort this out?

Also, all sorts of X configuration is currently done in sysloc.in, and much
like the python case I just completed I would rather use the automake macros
to configure X to simplify what we do if that is at all possible.

Also, there is the issue of static drivers which seemed to fail on all
platforms other than Debian. I will make sure they work both for RH7.3 and
the limited solaris system I have access to, but after that I rely on the
rest of the developers to test my fix (assuming the problem shows for one
of those two platforms) on all your accessible platforms.

Are there any other configuration changes anybody wants to tackle before
5.2.1 comes out?

Currently, I am thinking of releasing 5.2.1 on 1 March which gives roughly 4
weeks for us to improve the configuration and hammer the result with a
variety of tests on a variety of platforms so we don't get egg on our face
again.  However, that date is just a suggestion at this point.  If some of
the issues I mentioned above take longer than expected to fix we may have to
delay the release until even later.

Alan
__________________________
Alan W. Irwin
email: ir...@be...
phone: 250-727-2902

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the Canadian Centre for Climate Modelling and
Analysis (www.cccma.bc.ec.gc.ca) and the PLplot scientific plotting software
package (plplot.org).

__________________________

Linux-powered Science
__________________________