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