[GiNaC-list] How output from the configure script can be quite misleading

[Richard Haney]

When I first tried building CLN and GiNaC a few years ago, I got a
message from the configure script similar to the following, which is
the typical output in the most recent builds:

<begin quote>
checking whether make sets $(MAKE)... ./configure: eval: line 1:
unexpected EOF while looking for matching `"'
./configure: eval: line 2: syntax error: unexpected end of file
no
<end quote>

Sheplyakov Alexei's recent comments about building without modifying
Makefiles and my most recent tests seem to show that this error message
does not indicate a fatal error for the build process, but merely
indicates an "error" that is a "normal" result of the test and whose
potential ill consequences the configure script is quite able to
circumvent.

So when I first tried building CLN & GiNaC a few years ago, I think I
probably got a configure failure because readline headers and/or binary
library (libreadline.a) could not be found and/or because the CLN
library could not be found.  So when I found that configure did not
produce results that would allow an error-free build, I, as a newbie to
the process, began perusing all of the output to see if I could find
some clear indication as to why the build was failing.  The output
associated with "checking whether make sets $(MAKE)..." looked like a
problem that I needed to correct somehow (in addition to the problems
of getting the configure script to find headers and/or binary
libraries).  I don't recall how I stumbled upon the idea that letting
my Borland make answer the configure script's question would solve the
problem.  Perhaps I just didn't have my gnu make in any of my PATH
directories at some point.

Anyway, when my Borland make was answering the configure script's
question, the answer was simply a "yes" with no error messages. 
However, other tests showed that Borland make was not up to the task of
building the library.  So it seemed quite clear to me that I needed to
comment out my gnu make when I wanted to run configure and then restore
my gnu make when I wanted to run make.

It is my guess that this situation has probably resulted in a lot of
needless modification of Makefiles by me.

So the point of this message is that the quoted output above regarding
"checking whether make sets $(MAKE)" can be extremely misleading,
especially to a newbie.

If the configure script eventually comes up with the answer "no" (as
above), it seems very likely that there is no problem here that
requires "operator" intervention and/or adjustment in that regard,
regardless of the error messages produced in the interim.

Richard Haney


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com