[plt-scheme] Unix install (was Version Check)

On Thu, Apr 27, 2006 at 08:44:47PM -0600, Matthew Flatt wrote:
> We could use some help. Whether it's the filesystem layout, the package
> format, or anything else that bothers you, please help us fix it.

I had always assumed that the file organization and the package format
were deliberate design decisions rather than acknowledged deficiencies.
Certainly someone chose to design and implement the .plt file format
instead of using existing archive formats (possibly with some additional
metadata in a special file, like what jar does). So before something can
be "fixed", there has to be some kind of a consensus that the current
way is indeed bad and a change is in order. Certainly I'm not expecting
everyone to share my opinions on what is the Right Thing.

But, for what it's worth, here's how I think the PLT software _should_,
in an ideal world, be installed on a "standard" (FHS-compliant) Un*xish
filesystem hierarchy. Here "..." is stands for the installation prefix,
typically /usr or /usr/local.


Binaries: .../bin/

At least all the "full applications" (drscheme, mzscheme, mzc, slatex,
etc...) should go to .../bin where they are immediately in the user's
path. If anything is considered an "auxiliary binary" that is not meant
to be called directly by the user (help-desk, perhaps?), then it should
be placed somewhere under .../lib/plt/. The same goes for
framework-test, although tests probably should not be installed at all
by default. In any case, names like "help-desk", "web-server" and
"slideshow" are perhaps just a bit too generic for placing in a
directory that is shared with other software. Maybe they should be
prefixed with "plt-" or renamed altogether?


Common native libraries: .../lib/

"Common" means those libraries that a user may link directly against
when developing applications that embed mzscheme: libmzscheme, libmzgc,
libmred. When placed in .../lib/, a linker can find them without extra
path tuning.

I'm not sure what "mzdyn.o" is. I'm guessing that it should be under
.../lib/plt. The same goes for "buildinfo".


Common headers: .../include/plt

Again, "common" means anything that is needed for embedding. If there
are more than one or two headers for a library, it is good style to keep
them in a separate subdirectory, and I think that the threshold is met
here.

The mzc-specific headers are platform-independent (right?), so they can
probably also be installed under .../include/plt.


Man pages: .../man

Straightforward.


Scheme code: .../share/plt/

Scheme code is platform-independent and may be shared by multiple
architectures, so it should be placed under .../share.


Compiled scheme code: .../share/plt/

.zo files are a bit problematic. They are platform-independent, which
would place them under .../share, but "feel" more like binaries than
shared data, which would place them under .../lib. Also, they are
redundant and can be regenerated from other files, which fits the
description of /var/cache and /var/local/cache. Certainly, _if_ modules
were compiled on the fly and the compiled versions were cached, then
/var/cache would be the right place, although this kind of tweakery
would require playing with permissions. This is what man and tex do.

However, since the usual way is to compile everything once and for all
during installation, then .../share is probably the right place for the
.zo files. Especially so if .zo files ever get installed alone,
_without_ the source.


Native libraries for collections: .../lib/plt/

These are platform-dependent and not used directly by the user. Hence
they should be "hidden" under .../lib/plt. Perhaps there could be a
similar collection hierarchy under .../lib/plt as there is under
.../share/plt.


Documantation: .../share/doc/plt

All the documentation should be in one place. Now some is in
.../collects/doc and then there are doc.txt -files in all the
collections (except mzlib). It is also a bit inconvenient that all the
doc.txt -files have the same name: I often have a number of them open in
emacs, and it's a bit hard to know which is which when all you have are
buffers named doc.txt, doc.txt<2>, doc.txt<3> etc.

So perhaps the best way would be for the contents of current
collects/doc to be in .../share/doc/plt, and then move each foo/doc.txt
into .../share/doc/plt/collects/foo.txt.

Also everything currently under "notes" should be moved here.


That's about it. To me it seems that most of this can be accomplished
just by changing installation paths a bit. Locating the native code for
collections requires some extra work.


Someone mentioned that the "one application-specific directory" approach
is better because it is easier to uninstall, but this argument doesn't
really hold, since there are various package management systems to take
care of this. I use one of the very simplest, GNU Stow. With most
autotools-based software, all I have to do is:

./configure --prefix=$HOME/local
make
make install prefix=$HOME/local/stow/this-app
cd $HOME/local/stow
stow this-app

and everything just works.

However, with PLT it's not quite this simple. I do (approximately):

./configure --prefix=$HOME/local
make
make install prefix=$HOME/local/stow/plt-lib

cd $HOME/local/stow/
mkdir -p plt/lib
mv plt-lib plt/lib/plt
cd plt
ln -s lib/include lib/man lib/bin .
cd lib
ln -s plt/lib/* .
cd ../..
stow plt

And then I probably run setup-plt at some point. This works reasonably
well for my purposes: I get mzscheme into my path ($HOME/local/bin)
which is usually all that matters to me. Still, it's a bit awkward.

So, before we start talking about "fixing" the file layout, we need to
know what it should be changed to. I'd be rather surprised if everyone
agreed that the layout I suggested would be an improvement...


Lauri