[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
Hello!
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
paths).
> 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
http://www.chiark.greenend.org.uk/~sgtatham/bugs.html
first?
Best regards,
Alexei.
--
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