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