Re: New Maxima directory structure



Thanks for the input. I have interspersed my comments below.


On Sun, 2002-03-10 at 07:05, Vadim V. Zhytnikov wrote:
> 1)  Executables
> 
>    /usr/bin/                (%_bindir)
> 
> main mxaima script and all other miscellaneous executables.
> Usually wrapper scripts to  some real executables. If we really
> want different executables for different Maxima versions we
> can make scripts maxima<ver> and link maxima to
> maxima<ver>.

The maxima wrapper script in cvs takes a version argument. I think we
can maintain backward compatibility with the wrapper script, so one
version should be OK.

> 2) Real executables
> 
>    /usr/lib/maxima/<ver>/              (%_libexecdir)
>    /usr/lib/maxima/<ver>/<lisp>
> 
> (on my system libexec is mapped to lib).

OK. That's what we have now.

> 3) Share library files
> 
> I definitely don't want to mix these files
> with others so we have two options.
> 
>    /usr/share/maxima/<ver>/             (%_datadir)
> 
> In this case we reserve this directory to
> Maxima share library files _only_.  But If we want
> to install any other files into /usr/share/maxima/<ver>/
> (e.g. emacs modes see below) then I propose
> 
>    /usr/share/maxima/<ver>/sharelib/

OK. That makes sense. I guess "share" is being used in two different
senses if we stick with the first example. Will it be confusing that the
source files in "share" are installed in "sharelib"?

> 4) Emacs *.el and related files
> 
> Once again we have two options. We can either
> use some standard directory for elisp files
> 
>    /usr/share/emacs/site-lisp/maxima/
>    (or /usr/share/emacs/site-lisp/maxima/<ver>)
> 
> or Maxima share directory
> 
>    /usr/share/maxima/<ver>/emacs/
> 
> In either case this directory must be added to the
> directories where emacs can find them.

I have spent hours trying to figure out the right thing to do for the
emacs files. I will spare the list the boring details. Suffice it to say
that I am not happy with anyone's procedure for installing emacs files.
I propose to keep them in the maxima share directory and to provide a
script that will add/remove the hooks to this directory either in the
system emacs files or the users emacs files. For the rpm packaging,
there would be separate maxima-emacs and maxima-xemacs packages
independent of the base maxima packages.

> 5) Documentation
> 
>    /usr/share/doc/maxima/<ver>         (%_docdir)
>       or
>    /usr/share/doc/maxima-<ver>
> 
> with subdirs ./emaxima, ./html and others.

OK. I think I prefer the former.

> 6) Info and man pages should go into standard directories
> 
>    /usr/share/info                   (%_infodir)
>    /usr/share/man                   (%_mandir)

While that seems like the obviously correct solution, it violates the no
conflicts between multiple version rule. Any ideas?

> 7) Some other miscellaneous directories
> 
>    /usr/lib/menu                (%_menudir)
>       - menu entries

I that's a RedHat-specific thing, isn't it? Any entries there may be a
part of the RPM package only.

> 
>    /usr/share/texmf/tex/latex/exmaxima
>      - TeX style files.

I'm not thrilled about that one. I don't know if there is a
platform-independent way to do the TeX style file installation. I think
I would prefer the share directory.

>    /usr/share/icons           (%_iconsdir)
>       - icons.  BTW I could contribute .xpm icons but
> they are modeled after icons of commercial Macsyma
> icons (red M with the blue integral sign). Is it OK?
> I don't think they copyrighted them but if any
> trouble could expected I can make new ones.

I really don't think we should copy the commercial Macsyma icon. Maybe
we can find someone who would like to come up with a new icon for
Maxima?

> Finally some more proposals concerning new build system.
> 
> It seems to me that contrib is not necessary in the Maxima
> share library. Maybe it is better to place recently
> contributed files directly in the appropriate subdirectory
> of share library.

I think there is a point to contrib. Code can be put in contrib before
it has reached the level of scrutiny/testing that I would like to see
for the more official maxima components. With the current state of the
share directory the difference is not important, but I am thinking about
the long term.

> I think that it is necessary to add lisp initialization file
>    /usr/lib/maxima/<ver>/gcl/init.lisp
> to GCL version of Maxima. And execute this file every
> time GCL Maxima starts. This file should preallocate
> some memory since without it GCL is terribly slow.
> I hope that such GCL behavior will be improved
> in the future but some memory preallocation is highly
> desirable. In any case init.lisp can be empty.
> Afterthought: the best way is to check for
>    /usr/lib/maxima/<ver>/gcl/init.lisp
> and execute it is exists.

We can do something like that. It doesn't have to be specific to GCL. We
can allow for init's for any lisp implementation.

--Jim