[GiNaC-list] some flexibility problems with configure

[Richard Haney]

Since running the GiNaC's configure script typically takes a
considerable amount of time, it seems that there is a need for more
flexibility (as well as robustness and, of course, speed) in the
build/install process, and it seems that it is particularly important
that the INSTALL documentation should be especially clear on a number
of things in this regard.

A few years ago when I built CLN and GiNaC, I had a rather slow
computer.  It took me at least two weeks of several hours per day
running my computer to do the builds.  I also encountered a number of
"real bugs" and "false bugs" (e.g., the -- as of at least now --
misleading problem with configure's "checking whether make sets
${MAKE}").  After running configure and then make for many days and
then discovering that changing some files could clobber my Makefiles, I
became especially concerned about the possibility that some of the
extremely time-consuming builds of object files could be inadvertently
destroyed because of evident, but unclear, "Rube Goldberg" mechanisms
in Makefiles and the experimental adjustments I might try making.

I eventually figured out that I needed to keep backup copies of every
single version of Makefile modifications.  And I finally figured out
that I should run something like "make -k &> make_-k_out.txt" to
preserve a record and to make the best progress without having to
constantly check (over a period of several hours each day) whether the
make process has crashed on some bug.  (The output file
"make_-k_out.txt" then gets its name changed manually to something like
"make_-k_out--2006-08-05, 1..24 pm.txt" so it won't be clobbered by a
re-use of the command line.)  It seems some advice in this regard in
the INSTALL file would be a good idea.

Well, I now have a significantly faster computer and I suppose that
there have also been some improvements in the intrinsic robustness,
speed, and flexibility of GiNaC builds.

But the earlier concerns of mine seem still to be present, especially
for a new user of GiNaC and its build process.

It needs to be made clear what things a person can modify without
causing great havoc and having to start the build processes over from
scratch.  Hopefully, this could be done in a clear fashion without
requiring a high degree of special expertise (say of autoconf,
automake, configure, make, etc.) by the user.  Some Makefiles, in
particular, are extremely intricate and elaborate and seem to resemble
"Rube Goldberg" contraptions.  If the user discovers that something in
the make process is not working as expected, it seems a good idea to
allow him or her to make adjustments to Makefiles and/or perhaps other
files without causing irreversible havoc.  (This sort of thing has
seemed absolutely necessary in my build of readline, including a very
inelegant hack of the script "shlib-install" -- due to a "shift"
command not skipping the argument "C:/cygwin/bin/install -c -m 644"
(with quotes) as one entire unit -- in order for directory
"C:/gnu/readline-5.1/gcc342/bin" to be created and the DLLs installed
there as evidently intended.  This kind of thing makes a newbie wonder
what kind of horrendous debugging hoops he will have jump through in
building something like GiNaC.  Similar issues with bugs in CLN and
GiNaC compiler source files have recently been addressed here by
Sheplyakov Alexei and seemed to be still present this year after my
three-and-a-half-year hiatus from CLN and GiNaC builds.)

It seems to me that an extremely good idea is to make a general
practice of keeping separate software packages in separate file
hierarchies, especially when one is installing packages tentatively and
may want to delete or uninstall such packages later.  In other words,
it seems an extremely good idea to keep packages as mutually
independent as possible, and when dependence is necessary, to make it
very clear (by adding strategically named annotation files, for
example) what that dependence is.  (An exception would be several
standard packages that are designed by a single group -- e.g., MinGW --
for installation in a common hierarchy.)  I recall once deleting and/or
uninstalling my cygwin hierarchy "C:\cygwin" and then later deciding
that I wanted to re-install it.  Any important files added to the
hierarchy before deleting it would likely be lost without special care
to search the hierarchy's directories for past adjustments and
additions.  (For example, I have changed the name of "bunzip2.exe" to
"bunzip2.exe--DANGEROUS_DEFAULTS.exe" in "C:\cygwin\bin" and supplied a
script file "bunzip2" to execute "bunzip2.exe--DANGEROUS_DEFAULTS.exe"
using safer default options.)

And if any files get installed in the typical default "/usr/local",
those files would be a part of the "C:\cygwin" hierarchy (if using
cygwin bash) and thus would risk being lost should cygwin be
uninstalled (and/or updated).  So for these reasons I have preferred to
keep software packages and their "installations" in their own
hierarchies.  (So for example my preferred root installation directory
for GiNaC is "C:\gnu\ginac-1.3.4\gcc342" -- that's
"/cygdrive/c/gnu/ginac-1.3.4/gcc342" or "C:/gnu/ginac-1.3.4/gcc342" in
a cygwin bash context, especially where "\" has a special meaning.)  A
major motivation is the desire to initially install packages only
tentatively.  I want to be careful about loading my disk unnecessarily
with large numbers of packages that consume vast amounts of disk space.
 (For example, I have resisted installing the Microsoft's "free" C++
Visual Studio Express because the -- presumably much compressed --
installer consumes about 135 MB of storage and I am concerned the
actual installation could consume, say, a gigabyte of storage.)

I recently installed Dev-C++ because of comments I found on "Wikipedia"
comparing IDEs and especially because I wanted to have a "safe"
installation of the highly portable wxWidgets and because the Dev-C++
package incorporates all the essentials of MinGW gcc 3.4.2, the latest
stable version of gcc (at the time).  So now with my build of CLN and
GiNaC I have somewhat compromised my general plan of
package-installation independence and placed copies of various
libraries -- for example, "libtermcap.a", "libreadline.a",
"libhistory.a", "libgw32c.a", and now "libcln.a" and "libginac.a" -- in
my "C:\Dev-Cpp\lib" directory and various DLLs and "cln-config" in
"C:\Dev-Cpp\bin".  

("Filename" annotations added to these directories include, for
example, empty files
"cln-config--from 'C.._gnu_cln-1.1.11_gcc342_bin'.txt", 
"libreadline.5.dll from readline-5.1 build--see 'C.._gnu'.txt", and
"libginac.a from 'C.._gnu_ginac-1.3.4_gcc342_lib'.txt".  When a
directory is displayed in alphabetical order, such an annotation file
appears next to the associated "installed" file for quick reminder of
the "installed" file's origin.)

One possibility that may perhaps work when building GiNaC for example
is to use the rather long command
./configure CPPFLAGS="-IC:/gnu/cln-1.1.11/gcc342/include
-IC:/gnu/readline-5.1/gcc342/include
-IC:/gnu/termcap-1.3.1/gcc342/include"
LDFLAGS="-LC:/gnu/cln-1.1.11/gcc342/lib
-LC:/gnu/readline-5.1/gcc342/lib -LC:/gnu/termcap-1.3.1/gcc342/lib"
but this does not satisfy GiNaC configure's need to find "cln-config"
(in "C:/gnu/cln-1.1.11/gcc342/bin") and moreover it seems to be more
complication for the user than should be necessary.

It is not clear to me whether this would work for GiNaC builds with
appropriate prepackaging adjustments vis-a-vis GiNaC configure's
current need to find "cln-config" -- even if cygwin bash would allow
arbitrarily long command lines.  But it seems that some relatively
simple adjustment to GiNaC's packaging could allow for such simple,
flexible, package-independence processing by the user.  (See also the
autoconf-list archived message: "Re: nonstandard library directories"
(Bob Proulx, Thu, 29 Jun 2006 21:38:15 -0600):
http://lists.gnu.org/archive/html/autoconf/2006-06/msg00122.html )

It seems one possibility would be a command such as
./configure CLN="C:/gnu/cln-1.1.11/gcc342"
READLINE="C:/gnu/readline-5.1/gcc342"
TERMCAP="C:/gnu/termcap-1.3.1/gcc342"
This would of course require adjusting the GiNaC distribution
appropriately.  (Generally, I'm thinking that there should be some
easy, simple way of pointing to the various original package
installation directories.)

The advantage of this approach is that it allows the various library
build/installation packages to be storage-wise independent of any
centralized hierarchy such as "C:\Dev-Cpp", "C:\cygwin", or MinGW's
"C:\msys", and thus would allow for easier systems-packages management.

Another improvement that seems a good idea is in general to place a
single value -- such as, for example, the configure script's option
value of "--prefix" -- in one standard location that all Makefiles
would refer to, so that the user could simply modify that one value for
all Makefiles, in contrast to the present practice of repetitively
placing a given such value in every Makefile.  There are other files --
for example, script file "config.status" -- that also refer to the
"--prefix" value and would also need to be modified to refer to the
one, central, GiNaC-build information file for this information.  Of
course, such a facility should also be described sufficiently in the
INSTALL file.  (While "make install prefix=/path/to/wherever" may be a
good work-around for the "--prefix" value, there are many other values
which are repetitively placed throughout the Makefiles and which may
need to be modified; or perhaps they too could be treated similarly to
the "prefix=" example.  But it is important to include that information
in the INSTALL file.)  The idea, of course, is to improve the ease and
flexibility of the build process, especially when bugs are encountered
and especially in view of the fact that configure is a rather
time-consuming script to run and that building the library object files
and building the libraries after the object files are built are also
time-consuming, and even some of the tests are a bit time-consuming as
well.

I would like to hear what others think of the general idea and various
practices in managing software packages to be as mutually independent
as possible, except where dependence is really needed.  This is
particularly important in regard to GiNaC builds and installations --
as well as other software package builds and installations.  I would
also like to hear how this idea could or should be implemented for
GiNaC, especially along the lines suggested above, or what alternative
considerations and practices my be more appropriate.

Please note that, while many of the above details may seem irrelevant
from certain limited perspectives, I am supplying these details to give
a realistic idea of what a new user is faced with.  (And while the
examples given above are specific to "C:\Dev-Cpp", "C:\cygwin", or
MinGW's "C:\msys" in a Windows environment, the general issue of
systems-packages independence seems equally applicable to standard
Unix/Linux systems as well; but in the case of Unix, it seems there is
a whole lot of "ancient" systems legacy -- e.g., centralized
installation -- that may perhaps also need to be considered.)

As experience shows, it seems to me that the build process needs to be
designed to allow for the possibilities that bugs will appear and that
a relatively build-unspecialized user needs to respond to those bugs in
a flexible manner.

Richard Haney


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