[GiNaC-list] GiNaC is not a package manager (Was.. ...

[Richard Haney]

Alexei,

--- "Sheplyakov Alexei" <varg at 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