[gambit-list] Gambit installer

Adrien Pierard pierarda at iro.umontreal.ca
Wed Oct 1 05:33:05 EDT 2008


> What is the "installer"?  Are you referring to the Makefiles in the
> Gambit-C source, as they pertain to unix?  If so, I have some comments.

Yes.

> IMHO, the current method is better than your suggestion for multiple
> version installation in /usr/local/.

I'm not sure about that, hence this discussion, and a previous one in June
(which I didn't start).

> For the standard Gambit library package (libgambc4 and libgmabc4-dev)
> installation on Debian, the file layout is currently
> /usr/lib/libgambc.so.4.2.8
> ...
> /usr/lib/gambc4/_eval#.scm
> /usr/lib/libgambc.so.4               S
> ...
> The files marked with S are symlinks.

That's nearly what I want to be able to do easily.

> Putting the supporting files in /usr/lib/gambc4 is a good idea, because
> we don't want to clutter up /usr/lib/, and we'd never find them in the
> hundreds of files in /usr/lib, anyway.

The only issue I see there (as far as at least Marc and Christian are concerned)
is that you can't have two concurrent 4.x.y versions, can you ?
However, I consider that people using ports/packages would be more than happy
with this pattern, and that gambit hackers can build from the source and do what
they want.

> because you'd either have to recompile all your Gambit executables on
> every upgrade, or maintain all previous versions of the library, which
> is impractical.  You'd be far better off using static libs.
> ..
> What I would hope is that any executable compiled with Gambit 4.X.X
> could be dynamically linked with any later 4.X.X shared lib.  When ABI
> backwards compatibility is broken, then it's time for 5.0.0, a libgambc5
> package, and /usr/lib/gambc5.  I would hope this wouldn't happen more than
> once every couple of years, or less.

That's what I suggester: overwrite for minor upgrades, and create a new
installation path for major upgrades.

> But it isn't practical to have a bunch
> of point release packages installed and tracked in the Debian
> infrastructure.

Let me state this again: I don't want to decide where to install. I want
./configure to take as many arguments as possible so that one can decide to
install in /usr/v4.2.9/{lib,includes,info,...} as well as in
/usr/local/lib/gambit/4.2.9 or /usr/lib/libgambc4/ and so on. Currently, this is
a real pain in the neck to achieve and one has to tweak the makefiles manually
to get this result.

> A different subject.  Installing as gsi-4.2.9 is a little ugly, and
> doesn't really solve your name clash.  What are you planning to call
> your man pages?

I see no man page for gsi in the source.
If there were, and if they needed to be changed, that would probably mean a
major upgrade (or "medium" upgrade, such as 4.3) and then, one would probably
decide to create another version of gambit for his package manager (dpkg/apt-get).

> How about using gambci and gambcc?  That way, if people have scripts that

I don't mind. These are probably the best names. I currently use gsi-gambit and
gsc-gambit at home, but gambci and gambcc seem nice.

> /usr/share/doc/gambc-doc/examples/syntax-case.scm.gz    :-)
> but I would have no problem if it was in /usr/lib/gambc4/.
> > corresponding path (such as $prefix/lib/gambit-c/$version) where
> > everything needed is found, and where I plan to put syntax-case.scm
> "everything needed" ??
> On Debian following a standard
> (path-expand "~~") ->  "/usr" 

See, people using the source install with defaults find it in
"~~/syntax-case.scm" and you find it in
"~~/share/doc/gambc-doc/examples/syntax-case.scm"
So, with this, Debian is not consistent with most of the documentation of
gambit. That's why I suggest to have it in ~~/lib or in ~~ (depending on what ~~
means at the time the modified makefiles are used).

> (Note that Debian and Ubuntu are currently at 4.2.8. Updates to these

My ubuntu is still at 4.0b20 and never suggested I upgrade gambit...
Perhaps I should check why...

> The package installation system on Debian doesn't touch /usr/local/.

BSDs install all third party software in /usr/local

> I
> can install any number of vanilla upstream versions in
> /usr/local/Gambit-C/vX.X.X/, which can be helpful for development and
> packaging.  When I do that, ~~ expands to /usr/local/Gambit-C/vX.X.X/.
> In other words, it always points at the current install tree.  This is
> consistent, and works fine.

With my proposed modifications, you should be able to keep doing this.
Yet, FHS states: "No other directories, except those listed below, may be in
/usr/local after first installing a FHS-compliant system."
In other words, if you want to break this, you'll have to give extra parameters
to ./configure.

> If you want lib, then ~~/lib/ will do it, no matter which installation
> you're in.  If you do change this, you will need to update the Gambit
> documentation, and worry about existing code.

Again, some people say 'but I want to do "~~/info"' which anyway
won't work on debian, if I remember correctly what you wrote.
But I'm not sure that giving access to the doc through ~~ is mandatory...

> Note that with the current Debian configuration, the comments in the
> Gambit Manual Section 3.4.1 on compiler options are unnecessary, and so
> are -lm -ldl -lutil.  Everything just works.

It doesn't work on BSD. Debian probably uses implicit flags.

> It's already pretty good.   Most of the "fix" will just complicate
> things for the rest of us packagers.

I don't think so, though.

> Packaging is usually done in two stages.  First, build and do a dummy
> installation in a suitable place.  I do something like ...
> Then install the files into the final locations in the package from
> there using your distro's packaging tools and brute force, in some

You use a binary based package manager. For source based-package managers, one
can't do this. This means BSDs, and probably Gentoo.
Also, by moving the relative paths between your files in the package means that
"~~" isn't consisten anymore with what it was when you compiled (see the
"~~/info" example)

> It seems that you are planning on changing the first stage (what Gambit's
> make install does) to make it more convenient for your purposes.  Fine,
> but you are going to cause the other packagers pain, because we've already
> worked out all these details and will have to modify our packaging to
> undo your "fix". 

My purpose is FHS compliancy while letting those who like the current system be
able to use it. That might be a pain for some, but it's a price to pay just
*once* and a choice that should have been done ages ago.
When my changes are done and acceped (if ever), all you'll have to do is 
set a few variables in your build script and voila (just as any software
properly written: you set --prefix --bindir --infodir and so on)

> I've included a couple of patches below to give you an idea of what's
> involved.  The first one shows how the soname is created, and is
> something that might be good to add to the Gambit-C source.

I've patched the whole source at mine already to install it properly, and I kind
of know the makefiles as well as my first name now...

> -- 
> KBK


Final sample summary:

$prefix/$gambit-version-short-pre/$gambit-version-long-pre/{lib,info,include...}/$gambit-version-short-post/$gambit-version-long-post/

suggested values for
short is gambitc-v4
long is gambitc-v4.2.9
One can even think of
medium as gambitc-v4.2

"Old way install" is
./configure --prefix=/usr --gambit-version-long-pre=v4.2.9

"BSD way install with concurrent versions" is
./configure --prefix=/usr/local --gambit-version-long-post=gambit-c/v4.2.9 --gsi=gambci-4.2.9

"Suggested Debian way install" is
./configure --prefix=/usr/ --libdir-short=/usr/libgambc4 --infodir=/usr/doc/gambc/info


Apart from making the one writing those makefiles (aka me) swear a couple of
times, all users (including maintainers) should benefit from this scheme,
shouldn't they ?



Adrian

-- 
"I am not a Church numeral; I am a free variable!"
(The Scheme Underground)
For every complex problem, there is a solution that is simple, neat, and wrong.



More information about the Gambit-list mailing list