Re: [Plplot-devel] Make of plplot-5.2.0 fails on a freshly installed Red-Hat-8.0.

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

As you know all, I do not have time right now to work on PLplot.  Although,
I use to skim over the messages in the mailing list from time to time.
Joao's report below called my attention, because a non-compilable tarball is
a very serious problem and I find the bug report quite intriguing.

* João Cardoso <jc...@fe...> [2003-01-24 15:25]:

> [explanation of problem deleted]
>
> [jcard@clio plplot-5.2.0]$ make
> [some make messages deleted]
> Making all in include
> make[1]: Entering directory `/home/jcard/plplot-5.2.0/include'
> cd .. && /bin/sh /home/jcard/plplot-5.2.0/missing --run autoheader

This call to autoheader (through the `missing' script) should never, never,
I repeat: _NEVER_ happen when regular users run make.  None of the Autotools
should be called during a normal make, since this would defeat the very
purpose of the Autotools.  The only tools that are required for
configure/make are a Bourne shell and a regular make (not even GNU make).

Automake, for instance, should only be called from the Makefile when
developpers change one of the autotools source files (like aclocal.m4,
configure.ac, etc).  Something is really weird with the 5.2.0 distribution
tarball.

As I told before, I do not have time to plunge into this problem, but here
is a first try on its diagnosis:

When I run ./configure here on a freshly detarized 5.2.0 distribution, I get
the following rules in include/Makefile:

$(srcdir)/plConfig.h.in:  $(top_srcdir)/configure.ac $(ACLOCAL_M4)
$(top_srcdir)
/acconfig.h
        cd $(top_srcdir) && $(AUTOHEADER)
        touch $(srcdir)/plConfig.h.in

$(srcdir)/plDevs.h.in:  $(top_srcdir)/configure.ac $(ACLOCAL_M4)
$(top_srcdir)/a
cconfig.h
        cd $(top_srcdir) && $(AUTOHEADER)
        touch $(srcdir)/plDevs.h.in
	
This is a complete non-sense, since there are no src/plConfig.h.in and
src/plDevs.h.in to be built!  This is what is triggering the call to
autoheader from make, which should never, I repeat, never occurs for regular
users.

I have no clue about where the source of the problem is.  It is possibly
related to the assumptions that the macro AM_CONFIG_HEADERS makes about the
location of *.h.in files.  Of course, I am wildly guessing here.  

-- 
Rafael