[GiNaC-list] GiNaC is not a package manager (Was: some flexibility problems with configure)

Sheplyakov Alexei varg at theor.jinr.ru
Mon Aug 7 07:21:56 CEST 2006


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...

> especially when one is installing packages tentatively and
> may want to delete or uninstall such packages later. 
.. but nothing prevents you from using --prefix=/whatever/you/want.

> 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.
These dependences are specified in debian/* (and GiNaC.spec.in).

> and moreover it seems to be more  complication for the user than
> should be necessary.
You made this complication yourself (by choosing weird installation

> 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
> 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 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.

 think porting dpkg/APT to win32 would be better approach.
> 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.

May be this user should read 


Best regards,

All science is either physics or stamp collecting.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 827 bytes
Desc: Digital signature
Url : http://www.cebix.net/pipermail/ginac-list/attachments/20060807/adcd2797/attachment.pgp

More information about the GiNaC-list mailing list