Alexei, --- "Sheplyakov Alexei" <varg@theor.jinr.ru> wrote:
On Sun, Aug 06, 2006 at 04:20:11PM -0700, Richard Haney wrote:
It seems to me that an extremely good idea is to make a general practice of keeping separate software packages in separate file hierarchies,
This is in fact very bad idea...
I was hoping to stimulate a discussion of the pros and cons. Could you give some reasons? I suppose there are probably both good and bad reasons for the idea, and it seems that knowing the various reasons ahead of time could save having to deal with a lot of needless problems later. As packages are installed and built, a certain amount of commitment is built up over time, and thus, it can become costly to undo bad decisions. But it's not completely clear to me what all the potential problems might be one way or the other. I've indicated some considerations as to why I think the idea is a good one.
and moreover it seems to be more complication for the user than should be necessary.
You made this complication yourself (by choosing weird installation paths).
I was trying to suggest an approximate solution using _existing_ facilities in the GiNaC as distributed, as a lead-in to the next variation proposed, which seems a better, simpler approach, but would seem to require a modification of GiNaC distribution:
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"
GiNaC configure script provides --with-cln-prefix option
So it seems that perhaps this following command should work (without having to have the relevant libraries installed in a central, PATH-and/or-gcc-dependent repository): ./configure --with-cln-prefix="C:/gnu/cln-1.1.11/gcc342" CPPFLAGS="-IC:/gnu/readline-5.1/gcc342/include [-IC:/gnu/termcap-1.3.1/gcc342/include]" LDFLAGS="-LC:/gnu/readline-5.1/gcc342/lib [-LC:/gnu/termcap-1.3.1/gcc342/lib]" I've put the termcap references in brackets [] because it's not clear to me whether the bracketed parts are needed (in the next distributed version of GiNaC, at least). Would this work? It would probably take me at least a half day to test this. Does anyone see any problem with it? But note that there is some redundancy here in the command line. A preferred command line might be (omitting the termcap reference as well): ./configure --with-cln-prefix="C:/gnu/cln-1.1.11/gcc342" --with-readline-prefix="-IC:/gnu/readline-5.1/gcc342" This, of course, would require that the GiNaC distribution be modified accordingly and that the installation structure for readline be the standard one with the root directory the one specified.
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,
You might want to read autoconf manual, specifically the chapter about CONFIG_SITE variable.
I was thinking in terms of simple changes to the GiNaC distribution so that a new user wouldn't have to read the autoconf manual. One possibility would be to have an include file -- say, in the root build directory (i.e., with "configure") -- that each of the Makefiles would include to function as a part of each such Makefile.
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.
Long time ago package managers was written to solve these problems. If your OS lacks such a package manager, GiNaC is not going to provide one.
Well, I suppose a package manager might be one approach or part of a more general approach, but I wasn't thinking that special package management software would be necessarily a part of such a general approach. A human operator needs to make allocation planning and priority decisions at least. So some degree of manual operation seems necessary. I would hope for an appropriate management scheme/philosophy and simplified procedures. Allowing for or providing some additional support for flexibility here -- according to what the user prefers -- seems perhaps a good idea.
think porting dpkg/APT to win32 would be better approach.
I looked on the Internet and didn't find anything informative that I could examine to get an idea of what's involved in your suggestion. So at the moment porting dpkg/APT seems out of my reach as far as anything I could do. Best regards, Richard __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com