Hi everyone. With the new version of Gambit, I decided to take some time to fix the installer and chose to install gambit in $prefix/bin/{gsi-$version,gsc-$version} $prefix/lib/gambit-c/$version $prefix/doc/gambit-c/$version $prefix/share/gambit-c/$version $prefix/info/gambit-c/$version $prefix/include/gambit-c/$version (the hardcoded "gambit-c" couls also be a variable, for those who run only one version of gambit and want to install directly into the $prefix subtree.) This should hopefully allow those who want to run several versions of gambit at once to do so (which explains the current behaviour of the installer), and also avoid clashes with names already taken by other binaires (such as ghostscript). Yet, there's two issues for which I need your advice: - Where should I put syntax-case.scm? - What happens to the shortcut "~~" in file paths? ideally, "~~" should be expanded by the binaries into the corresponding path (such as $prefix/lib/gambit-c/$version) where everything needed is found, and where I plan to put syntax-case.scm The aim of this "fix" is to make gambit fully portable and configurable on as many OSs as possible. So ? 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.
Afficher les réponses par date
Adrien Pierard wrote:
Hi everyone.
With the new version of Gambit, I decided to take some time to fix the installer and chose to install gambit in
What exactly is broken with the current installation scheme? (Is it a problem because some systems don't support symlinks?)
$prefix/bin/{gsi-$version,gsc-$version}
Where will gsi-script and gsc-script be? Also, I'm missing where the "gsi" and "gsc" binaries/names will reside.
$prefix/lib/gambit-c/$version $prefix/doc/gambit-c/$version $prefix/share/gambit-c/$version $prefix/info/gambit-c/$version $prefix/include/gambit-c/$version
Why is this better than /usr/local/Gambit-C/$version/{lib,doc,info,include} ?
(the hardcoded "gambit-c" couls also be a variable, for those who run only one version of gambit and want to install directly into the $prefix subtree.)
This should hopefully allow those who want to run several versions of gambit at once to do so (which explains the current behaviour of the installer), and also avoid clashes with names already taken by other binaires (such as ghostscript).
Debian does not seem to have a conflict of the gsi and gsc names with ghostscript (http://packages.debian.org/search?searchon=contents&keywords=gsc&mode=exactf... and http://packages.debian.org/search?searchon=contents&keywords=gsi&mode=exactf... don't show ghostscript, only gambc.) so which OS'es do have one?
Yet, there's two issues for which I need your advice: - Where should I put syntax-case.scm? - What happens to the shortcut "~~" in file paths?
ideally, "~~" should be expanded by the binaries into the corresponding path (such as $prefix/lib/gambit-c/$version) where everything needed is found, and where I plan to put syntax-case.scm
I'm using "~~/lib/_gambit#.scm" and "~~/lib/gambit#.scm" in a number of places. Also I guess a number of people are using "~~/syntax-case.scm" currently. If those are to be changed, what are the reasons and aims? Christian.
On Mon, Sep 29, 2008 at 11:14:20PM +0200, Christian Jaeger wrote :
$prefix/bin/{gsi-$version,gsc-$version} Where will gsi-script and gsc-script be? Well, there, with the version though. One may keep the names without versions as symlinks to the latest version.
Also, I'm missing where the "gsi" and "gsc" binaries/names will reside. Just above, as explained
$prefix/lib/gambit-c/$version $prefix/doc/gambit-c/$version $prefix/share/gambit-c/$version $prefix/info/gambit-c/$version $prefix/include/gambit-c/$version Why is this better than /usr/local/Gambit-C/$version/{lib,doc,info,include} ?
Because that's how the unix tradition is ! Almost all programs follow these rules (at least the fedora of the university, all all my BSD OSs). As the maintainer of gambit on FreeBSD, I'd like to follow this scheme (as Perl and TCL do among many others)
Debian does not seem to have a conflict of the gsi and gsc names with ghostscript so which OS'es do have one?
BSD's. Debian and Ubuntu are well spread, but far from being the only unices around. I tend to think that some other linuxes hava this conflict.
I'm using "~~/lib/_gambit#.scm" and "~~/lib/gambit#.scm" in a number of places. Also I guess a number of people are using "~~/syntax-case.scm" currently. If those are to be changed, what are the reasons and aims?
from "~~", it seems one can only access either syntax-case or lib. What's the point? Why not have them packaged together, and then, get rid of the "lib" part of this shortcut? I believe that it's the right thing to do to merge them. Then, it's just a matter of a sed one liner to fix all the programs (which anyway need to be stopped when upgrading to a newer version of gambit).
Christian.
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.
Adrien Pierard wrote:
On Mon, Sep 29, 2008 at 11:14:20PM +0200, Christian Jaeger wrote :
$prefix/bin/{gsi-$version,gsc-$version}
Where will gsi-script and gsc-script be?
Well, there, with the version though. One may keep the names without versions as symlinks to the latest version.
Also, I'm missing where the "gsi" and "gsc" binaries/names will reside.
Just above, as explained
But then you can't choose which Gambit binary to use by setting PATH anymore. Environment variables are the best way to choose between alternatives; unix environment variables are what |make-parameter| is in Scheme. It allows for parametrization of programs without having to pass data lexically (for which the pendant in unix would be program arguments), and without having to do it by side-effecting globals (which in unix would be changing the symlinks you mention above).
$prefix/lib/gambit-c/$version $prefix/doc/gambit-c/$version $prefix/share/gambit-c/$version $prefix/info/gambit-c/$version $prefix/include/gambit-c/$version
Why is this better than /usr/local/Gambit-C/$version/{lib,doc,info,include} ?
Because that's how the unix tradition is !
What tradition exactly? You mean using $prefix/{lib,doc,share,info}? For example apache had (maybe still has, dunno) the tradition to do it like Gambit by default, i.e. put all of it's files into one common subdirectory (the advantage being that you can easily uninstall the whole program by just deleting one directory -- a bit like OS X is doing it now I think, btw). If you start creating subdirectories and thus deviate from standard places anyway (i.e. once you feel the need to add library paths to the ld config to avoid having to set LD_LIBRARY_PATH), it doesn't matter anymore?
Almost all programs follow these rules (at least the fedora of the university, all all my BSD OSs). As the maintainer of gambit on FreeBSD, I'd like to follow this scheme (as Perl and TCL do among many others)
What does it solve for you?
Debian does not seem to have a conflict of the gsi and gsc names with ghostscript so which OS'es do have one?
BSD's.
What is the conflict there?
Debian and Ubuntu are well spread, but far from being the only unices around. I tend to think that some other linuxes hava this conflict.
I don't intend to refute this, I just don't know, that's why I'm asking.
I'm using "~~/lib/_gambit#.scm" and "~~/lib/gambit#.scm" in a number of places. Also I guess a number of people are using "~~/syntax-case.scm" currently. If those are to be changed, what are the reasons and aims?
from "~~", it seems one can only access either syntax-case or lib. What's the point? Why not have them packaged together, and then, get rid of the "lib" part of this shortcut? I believe that it's the right thing to do to merge them.
So you are proposing two changes: (a) move files to different installation places in the filesystem, i.e. changing the exec and linker paths. (b) change the include (sub-)paths
Then, it's just a matter of a sed one liner to fix all the programs
Not quite, if you don't know in advance whether your program is going to be used with a Gambit version from before or after your changes. Christian.
Christian Jaeger wrote:
What does it solve for you?
My *guess* is that you want to make it possible to have several (binary) distribution packages of different versions of Gambit in FreeBSD/whatever, and create (binary) distribution packages depending on a particular one of them (like have a library foo-0.6 which works (i.e. is compiled) for Gambit 4.2.10 and a library foo-0.8 which works for Gambit 4.2.12; and you wouldn't want to depend on environment variables there but on fixed paths or postfixes. This kind of game is really usually being solved as you describe, by having a /usr/bin/python2.5 and a /usr/lib/python2.5/ alongside /usr/bin/python2.4 and /usr/lib/python2.4/, and then have a symlink /usr/bin/python -> python2.5 . Note: - with the current Gambit installation paths the same goal is still possible just as well (you'd refer to /usr/local/Gambit-C/v4.2.6/bin/gsc for example); I agree that it's not standard for binary distribution packages, though. - choosing between Gambit versions by using an environment variable is having the aim in mind to try a program with several different Gambit's without having to change the program's source code or make files; i.e. it's something with developers in mind. - so the art here is to keep the possibility to choose between Gambit versions by changing PATH and still be able to generate a FreeBSD / FHS[*] 'compatible' filesystem layout (and do this without using symlinks on Windows?). [*] http://en.wikipedia.org/wiki/Filesystem_Hierarchy_Standard (For me, the developer view is more important currently; also it's not clear yet how module systems might be coming into play here; so if in doubt, not changing might be the better option. In any case, be prepared to change again once module systems are here.)
from "~~", it seems one can only access either syntax-case or lib.
I've checked the manual for "~~", and there are more uses to it than just syntax-case and lib. «When the interpreter starts off it tries to execute a `(load "~~/gambcext")' (for an explanation of how file names are interpreted see Host environment). An error is not signaled when the file does not exist. Interpreter extensions and patches that are meant to apply to all users and all modes should go in that file.» «The `-l' option is only meaningful when an incremental link file is being generated (i.e. the `-link' option appears on the command line and the `-flat' option is absent). The `-l' option specifies the link file (without the `.c' extension) of the base library to use for the incremental link. By default the link file of the Gambit runtime library is used (i.e. `~~/lib/_gambc.c').» You can get the current ~~ path with: $ gsi -e '(display (path-expand "~~")) (newline)' /usr/local/Gambit-C/v4.2.6/ This means that you can get the correct paths corresponding to the "gsi"/"gsc" binary being found in the current PATH. For example you could have an .emacs file which loads gambit.el directly for the current gsi/gsc from this location: $ ls -l "$(gsi -e '(display (path-expand "~~/share/emacs/site-lisp/gambit.el"))')" -rw-r--r-- 1 root staff 23948 2008-07-26 18:32 /mnt/rootextend/usr/local/Gambit-C/v4.2.6/share/emacs/site-lisp/gambit.el Or have a document viewer which shows the doc for the currently choosen gsi/gsc: $ links "$(gsi -e '(display (path-expand "~~/doc/gambit-c.html"))')" Or have makefiles which do the right things for the currently choosen gsi/gsc: $ gcc ... -I"$(gsi -e '(display (path-expand "~~/include"))')" ... It may be sensible to move ~~/syntax-case to ~~/lib/syntax-case, and since I'm not using syntax-case I won't object; for other people, maybe a symlink from the old to the new place would be helpful (but then again, what's the state of things on M$Windows regarding symlinks?). (BTW, you can change what ~~ means by use of another environment variable: «A path which starts with the characters `~~/' denotes a file in the Gambit installation directory. This directory is normally `/usr/local/Gambit-C/version' under UNIX and Mac OS X and `C:/Gambit-C/version' under MSDOS and Microsoft Windows. To override this binding under UNIX, Mac OS X, MSDOS and Microsoft Windows, use the `-:=<dir>' runtime option or define the `GAMBCOPT' environment variable.» ) Christian. (PS. for some reason your emails had a Reply-To header set to the gambit mailing list; so I guess you don't want to receive Cc's to your address.)
(Christian Jaeger wrote:
I've checked the manual for "~~", and there are more uses to it than just syntax-case and lib.
I forgot to mention: Gambit is not currently installing a .a file if it is being configured with --enable-shared. (The .a file would also be in a ~~ location.) Currently the way to get a .so for dynamic linking on the local system and to also get a .a file for static linking for creating static executables is to install Gambit twice; just something to keep in mind, if you want to provide a gambc-dev package including a .a file then this may need a change too. Christian.)
On Tue, Sep 30, 2008 at 10:50:39AM +0200, Christian Jaeger wrote :
Christian Jaeger wrote: My *guess* is that you want to make it possible to have several (binary) distribution packages of different versions of Gambit in
Actually *I* don't at all. But Marc does, so I want the new installer to be Marc-compliant while being maintainers-and-OSs-friendly.
- with the current Gambit installation paths the same goal is still possible just as well (you'd refer to /usr/local/Gambit-C/v4.2.6/bin/gsc for example); I agree that it's not standard for binary distribution packages, though.
That's the main point yes.
- choosing between Gambit versions by using an environment variable is having the aim in mind to try a program with several different Gambit's without having to change the program's source code or make files; i.e. it's something with developers in mind.
I think that developers do whatever they want at home, but that the user shouldn't pay for this. And that work must be done too to help maintainers offer easily the software for as many users as possible. Also, if you want to use the environment, then you can do PATH=/path/to/gambit/bin:$PATH But John Doe shouldn't have to do so.
- so the art here is to keep the possibility to choose between Gambit versions by changing PATH and still be able to generate a FreeBSD / FHS[*] 'compatible' filesystem layout (and do this without using symlinks on Windows?).
I don't know windows. If a symlink is a real issue, storage isn't.
(For me, the developer view is more important currently; also it's not clear yet how module systems might be coming into play here; so if in doubt, not changing might be the better option. In any case, be prepared to change again once module systems are here.)
I don't know of this could influence the filesystem hierarchy. But hypothetical induction should not hinder evolution. Since I suggest a highly modifiable installer, that shouldn't bee too hard anyway.
I've checked the manual for "~~", and there are more uses to it than just syntax-case and lib.
Ok.
«When the interpreter starts off it tries to execute a `(load "~~/gambcext")' (for an explanation of how file names are interpreted see Host environment). An error is not signaled when the file does not exist. Interpreter extensions and patches that are meant to apply to all users and all modes should go in that file.»
that's typical $prefix/etc/gambit-c/config and ~/.gambit-c/config configuration
«The `-l' option is only meaningful when an incremental link file is being generated (i.e. the `-link' option appears on the command line and the `-flat' option is absent). The `-l' option specifies the link file (without the `.c' extension) of the base library to use for the incremental link. By default the link file of the Gambit runtime library is used (i.e. `~~/lib/_gambc.c').»
that's ~~/lib as I said.
You can get the current ~~ path with: This means that you can get the correct paths corresponding to the "gsi"/"gsc" binary being found in the current PATH.
Adding support for this isn't too hard... -D__GAMBCETC -D___GAMBCLIB and so on... It's already quite the case.
$ links "$(gsi -e '(display (path-expand "~~/doc/gambit-c.html"))')"
That's not worthy to me
$ gcc ... -I"$(gsi -e '(display (path-expand "~~/include"))')" ...
I suugest the usual gcc ... `gambit-conf --cflags` `gambit-config --libs`
Christian. (PS. for some reason your emails had a Reply-To header set to the gambit mailing list; so I guess you don't want to receive Cc's to your address.)
Bad muttrc. P! -- "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.
On Tue, Sep 30, 2008 at 12:23:17AM +0200, Christian Jaeger wrote :
But then you can't choose which Gambit binary to use by setting PATH anymore.
Well, actually, I would suggest *not* having several instances of gambit. More on this below.
Environment variables are the best way to choose between alternatives; unix environment variables are what |make-parameter| is in Scheme. It allows for parametrization of programs without having to pass data lexically (for which the pendant in unix would be program arguments), and without having to do it by side-effecting globals (which in unix would be changing the symlinks you mention above).
The only program I'm aware of that works this way is the autotools (which I don't like at all).
What tradition exactly? You mean using $prefix/{lib,doc,share,info}? For example apache had (maybe still has, dunno) the tradition to do it like Gambit by default, i.e. put all of it's files into one common subdirectory (the advantage being that you can easily uninstall the whole program by just deleting one directory -- a bit like OS X is doing it now I think, btw). If you start creating subdirectories and thus deviate from standard places anyway (i.e. once you feel the need to add library paths to the ld config to avoid having to set LD_LIBRARY_PATH), it doesn't matter anymore?
As far as I know, that's the case for apache 1.3 and apache 2. That's a big version difference. In that sense, I would personnally (by default, though configurable) have just one directory per X.Y version. All X.Y.* would be in the same place, for this is bugfixes or improvements that happen in a minor version upgrade. Your approach is much like what Gobolinux does though, but then, it's a layer above the "standard" one.
What does it solve for you?
A huge script and makefile can be avoided to make the installation compliant with what is expected by all BSD users (where files go, only one version at time of the software), and I do believe it would help us have an up to date version of gambit in software distributions of most OSs (which of your Linux offers 4.2.9 or even 4.2.8 ? Not Debian/Ubuntu)
What is the conflict there?
gsi and gsc are names already taken for binaries.
(a) move files to different installation places in the filesystem, i.e. changing the exec and linker paths. (b) change the include (sub-)paths
Yes.
Then, it's just a matter of a sed one liner to fix all the programs Not quite, if you don't know in advance whether your program is going to be used with a Gambit version from before or after your changes.
Minor update: the newer version can just do better than the previous one. Major update: new path (and since it's a major update, *you* are responsible for checking the consistency of your code with respect to the update).
Christian.
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.
Email is a very difficult means of communication at times. I'll just put my wishes here: - please don't remove the possibility to install multiple versions of Gambit easily - please don't remove the possibility to choose between those by only relying on environment variables - if it's possible to avoid requiring fixes by people using Gambit, please do avoid it (and otherwise, if you describe the necessary fixes and the reasons clearly, I'm sure people will be happier accepting the change(s)) Christian.
On Mon, Sep 29, 2008 at 11:29:58AM -0400, Adrien Pierard wrote :
- What happens to the shortcut "~~" in file paths?
After a discussion with Christian on IRC, I got the fllowing idea (something à-la PLT's require): (include doc "gambit.html") (load extra "syntax-case.scm") (include lib "gambit#.scm") (load "file_here.scm") where "doc" expands to the corresponding doc directory known at compile time of gambit, and so on. That way, we get rid of "~~" actually, but gain in modularity. One could even override this with the Perl way: (include (get-env "$GAMBCDOC") "gambit.html") where $GAMBCDOC is a list of documentation directories provided by the environment when calling the program. This requires small tweaks in gambit's source code, but isn't a big issue... Your opinion? 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.
Adrien Pierard wrote:
One could even override this with the Perl way: (include (get-env "$GAMBCDOC") "gambit.html")
(small detail: there is |getenv| already, which doesn't expect a dollar sign: for example (getenv "PATH").)
where $GAMBCDOC is a list of documentation directories provided by the environment when calling the program.
The "Perl way", and the only way making this useful (i.e. standard and consistent for all code) would be to have the system handle the environment variables transparently. If you say "use Foo;" in Perl, it will look at the @INC array of paths, which is dependent on: - a few paths fixed at Perl's configure/compile time - paths given in the PERL5LIB (or PERLLIB) environment variable(s) - additionally any occurrence of "use lib '/some/where';" in the loaded Perl program adds (well prepends) to the @INC array, too.
(include doc "gambit.html") (load extra "syntax-case.scm") (include lib "gambit#.scm") (load "file_here.scm")
I don't think you usually want to use |include| for doc or other non-"lib" directories (well once syntax.case.scm has moved into lib, anyway), and likewise there's no use for lib and so on if you want to get at the doc basedir. So I suggest this instead: - keep the current forms and procedures single-argument - interpret ~~ in paths given to them differently; i.e. move from ~~ meaning a single location to meaning whatever paths are sensible for a given function/form. - search non-absolute (i.e. ~~ and relative paths) given to the procedures and forms in path lists, which are being determined by (a) configure time hard-coded ones, (b) determined by some environment variable, (c) changeable by the user by changing a parameter object. This makes it really as flexible as paths handled in Perl, it avoids having to clutter up the above forms, and stays backwards compatible. A complete implementation of these features can be found here: http://scheme.ch/gambit/experimental/paths/paths.scm git clone http://scheme.ch/gambit/experimental/paths/.git Christian.
On Mon, Sep 29 2008, Adrien Pierard wrote:
With the new version of Gambit, I decided to take some time to fix the installer
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.
and chose to install gambit in
$prefix/bin/{gsi-$version,gsc-$version} $prefix/lib/gambit-c/$version $prefix/doc/gambit-c/$version $prefix/share/gambit-c/$version $prefix/info/gambit-c/$version $prefix/include/gambit-c/$version
(the hardcoded "gambit-c" couls also be a variable, for those who run only one version of gambit and want to install directly into the $prefix subtree.)
This should hopefully allow those who want to run several versions of gambit at once to do so (which explains the current behaviour of the installer),
IMHO, the current method is better than your suggestion for multiple version installation in /usr/local/. 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/libgambcgsc.so.4.2.8 /usr/lib/libgambcgsi.so.4.2.8 /usr/lib/gambc4/_eval#.scm /usr/lib/gambc4/_gambit#.scm /usr/lib/gambc4/_io#.scm /usr/lib/gambc4/_kernel#.scm /usr/lib/gambc4/_nonstd#.scm /usr/lib/gambc4/_num#.scm /usr/lib/gambc4/_repl#.scm /usr/lib/gambc4/_std#.scm /usr/lib/gambc4/_system#.scm /usr/lib/gambc4/_thread#.scm /usr/lib/gambc4/digest#.scm /usr/lib/gambc4/digest.scm /usr/lib/gambc4/gambit#.scm /usr/lib/gambc4/r4rs#.scm /usr/lib/gambc4/r5rs#.scm /usr/lib/gambc4/_gambc.c /usr/lib/gambc4/_gambcgsc.c /usr/lib/gambc4/_gambcgsi.c /usr/lib/libgambc.so.4 S /usr/lib/libgambcgsc.so.4 S /usr/lib/libgambcgsi.so.4 S /usr/lib/libgambcgsi.so S /usr/lib/libgambcgsc.so S /usr/lib/libgambc.so S The files marked with S are symlinks. 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. (As an aside, the Gambit source is now creating three shared libs. This caused me some pain, because it's three times as much to move around during packaging if something changes. Why three?) Gambit has the possibility of creating stand-alone executables linked to a dynamic library. This is very nice, but one thing I haven't seen discussed is the backwards ABI compatibility. I've seen a hint that a Gambit executable will only run with the exact point version shared lib it was linked with. That would defeat the usefulness of the shared lib, 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. Think about this in terms of other shared libs you work with! 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. I bring this up because I think the versioning scheme you are proposing differs from standard practice, especially for shared libs. As we move to Gambit-C 5, it might make sense to keep the libgambc4 package installed for awhile to support old apps built with Gambit-C 4 which haven't yet moved to Gambit-C 5. But it isn't practical to have a bunch of point release packages installed and tracked in the Debian infrastructure.
and also avoid clashes with names already taken by other binaires (such as ghostscript).
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? How about using gambci and gambcc? That way, if people have scripts that call these executables, they won't have to constantly update them. On Debian, I'll just symlink gsi and gsc. We don't have a clash, I think because gambit was there first. Ghostscript is gs.
Yet, there's two issues for which I need your advice: - Where should I put syntax-case.scm?
I've got it in /usr/share/doc/gambc-doc/examples/syntax-case.scm.gz :-) but I would have no problem if it was in /usr/lib/gambc4/.
- What happens to the shortcut "~~" in file paths?
ideally, "~~" should be expanded by the binaries into the 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 $ apt-get install gambc gambc-doc (path-expand "~~") -> "/usr" (Note that Debian and Ubuntu are currently at 4.2.8. Updates to these systems occur automatically during the system wide upgrades once gambc is installed for the first time. I'll upload the next release to unstable once Debian Lenny is released - RSN! I'm keeping unstable open in case an RC bug in 4.2.8 pops up which needs a fix. So far, so good.) The package installation system on Debian doesn't touch /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. 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. 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.
The aim of this "fix" is to make gambit fully portable and configurable on as many OSs as possible.
It's already pretty good. Most of the "fix" will just complicate things for the rest of us packagers. Packaging is usually done in two stages. First, build and do a dummy installation in a suitable place. I do something like $(MAKE) install prefix=$(CURDIR)/debian/tmp/usr \ PACKAGE_SUBDIR="" ^^^^^^^^^^^^^^^^^ this gets rid of the v4.2.8/ Then install the files into the final locations in the package from there using your distro's packaging tools and brute force, in some clever combination. The locations can differ from what you might consider a unix "standard". For example, on Debian the info files go into /usr/share/info, and the docs into /usr/share/doc/gambc-doc/ 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". OTOH, putting the supporting files in .../lib/gambc4 is a good thing. 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. The second one allows Gambit to find the supporting files in /usr/lib/gambc4. Right now, it needs a bootstrap, and it would be nice if that could be eliminated. -- KBK #!/bin/sh /usr/share/dpatch/dpatch-run ## 100_pass_soname_when_linking.dpatch by Kurt B. Kaiser <kbk@shore.net> ## ## DP: Support passing soname when linking libgambc; install libgambc as ## DP: libgambc.so.4 and install links libgambc.so.4 and libgambc.so ## DP: Also do the same for libgambcgsc.so and libgambcgsi.so ## DP: Upstream is now creating three shared libs. @DPATCH@ diff -urNad gambc~/configure.ac gambc/configure.ac --- gambc~/configure.ac 2008-06-04 18:20:15.000000000 -0400 +++ gambc/configure.ac 2008-06-04 18:20:17.000000000 -0400 @@ -12,6 +12,19 @@ PACKAGE_SUBDIR="/$PACKAGE_VERSION" #PACKAGE_SUBDIR="" +LIB_NAME="lib$PACKAGE_SHORTNAME" +TRIPLET_VERSION=$(echo $PACKAGE_VERSION | sed -e "s/v//") +LIB_VERSION=${LIB_NAME}.so.$TRIPLET_VERSION +LIB_SONAME=${LIB_NAME}.so.4 + +GSC_LIB_NAME=${LIB_NAME}gsc +GSC_LIB_VERSION=${GSC_LIB_NAME}.so.$TRIPLET_VERSION +GSC_LIB_SONAME=${GSC_LIB_NAME}.so.4 + +GSI_LIB_NAME=${LIB_NAME}gsi +GSI_LIB_VERSION=${GSI_LIB_NAME}.so.$TRIPLET_VERSION +GSI_LIB_SONAME=${GSI_LIB_NAME}.so.4 + AC_SUBST(PACKAGE_SHORTNAME) AC_SUBST(PACKAGE_NAME) AC_SUBST(PACKAGE_VERSION) @@ -1196,6 +1209,14 @@ SETDLPATH="LIBPATH=\$(rootfromhere)/lib:\$(rootfromhere)/gsi:\$(rootfromhere)/gsc:\${LIBPATH}" ;; + # Debian: + linux* | kfreebsd* | hurd*) + GAMBCLIB=$LIB_VERSION + GAMBCGSCLIB=$GSC_LIB_VERSION + GAMBCGSILIB=$GSI_LIB_VERSION + SETDLPATH="LD_LIBRARY_PATH=\$(rootfromhere)/lib:\$(rootfromhere)/gsi:\$(rootfromhere)/gsc:\${LD_LIBRARY_PATH}" + ;; + *) GAMBCLIB="libgambc.so" GAMBCGSCLIB="libgambcgsc.so" GAMBCGSILIB="libgambcgsi.so" @@ -1203,8 +1224,18 @@ ;; esac - MAKE_LIBRARY='$(C_COMPILER) $(FLAGS_LIB) -o $(LIBRARY) $(LIBRARY_OBJECTS) $(MAKE_LIBRARY_LIBS) $(LIBS)' - MAKE_LIBRARY_FOR_INSTALL='$(C_COMPILER) $(FLAGS_LIB) -o $(LIBRARY) $(LIBRARY_OBJECTS) $(MAKE_LIBRARY_FOR_INSTALL_LIBS) $(LIBS)' + if test $GAMBCLIB = $LIB_VERSION; then + MAKE_LIBRARY='$(C_COMPILER) $(FLAGS_LIB) -Wl,-soname,$(LIB_SONAME) -o $(LIBRARY) $(LIBRARY_OBJECTS) $(MAKE_LIBRARY_LIBS) $(LIBS)' + else + MAKE_LIBRARY='$(C_COMPILER) $(FLAGS_LIB) -o $(LIBRARY) $(LIBRARY_OBJECTS) $(MAKE_LIBRARY_LIBS) $(LIBS)' + fi + + if test $GAMBCLIB = $LIB_VERSION; then + MAKE_LIBRARY_FOR_INSTALL='$(C_COMPILER) $(FLAGS_LIB) -Wl,-soname,$(LIB_SONAME) -o $(LIBRARY) $(LIBRARY_OBJECTS) $(MAKE_LIBRARY_FOR_INSTALL_LIBS) $(LIBS)' + else + MAKE_LIBRARY_FOR_INSTALL='$(C_COMPILER) $(FLAGS_LIB) -o $(LIBRARY) $(LIBRARY_OBJECTS) $(MAKE_LIBRARY_FOR_INSTALL_LIBS) $(LIBS)' + fi + FIXLIB='#' LINK='$(C_COMPILER) $(FLAGS_EXE) $(EXECUTABLE_OBJECTS) $(LINK_LIBS) $(LIBS) -o $(EXECUTABLE)' LINK_FOR_INSTALL='$(C_COMPILER) $(FLAGS_EXE) $(EXECUTABLE_OBJECTS) $(LINK_FOR_INSTALL_LIBS) $(LIBS) -o $(EXECUTABLE)' @@ -1341,6 +1372,10 @@ AC_SUBST(bat) AC_SUBST(SETDLPATH) AC_SUBST(GSC_CC_O) +AC_SUBST(LIB_VERSION) +AC_SUBST(LIB_SONAME) +AC_SUBST(GSC_LIB_SONAME) +AC_SUBST(GSI_LIB_SONAME) AC_SUBST(GAMBCLIB) AC_SUBST(GAMBCGSCLIB) AC_SUBST(GAMBCGSILIB) diff -urNad gambc~/gsc/makefile.in gambc/gsc/makefile.in --- gambc~/gsc/makefile.in 2008-06-04 18:20:15.000000000 -0400 +++ gambc/gsc/makefile.in 2008-06-04 18:20:17.000000000 -0400 @@ -30,8 +30,10 @@ LIBS = @LIBS@ GAMBCLIB = @GAMBCLIB@ +LIB_VERSION = @LIB_VERSION@ GAMBCGSCLIB = @GAMBCGSCLIB@ GAMBCGSILIB = @GAMBCGSILIB@ +LIB_SONAME = @GSC_LIB_SONAME@ INSTALL = @INSTALL@ INSTALL_DATA = @INSTALL_DATA@ INSTALL_LIB = @INSTALL_LIB@ @@ -146,6 +148,11 @@ $(LIBRARY): $(LIBRARY_OBJECTS_IN_COMPILE_ORDER) rm -f $(LIBRARY) @MAKE_LIBRARY@ + # needed for bootstrap: + if test $(GAMBCLIB) = $(LIB_VERSION); then \ + ln -sf $(GAMBCGSCLIB) $(LIB_SONAME); \ + ln -sf $(LIB_SONAME) libgambcgsc.so; \ + fi _gambcgsc.c: $(LIBRARY_MODULES_C) $(rootfromhere)/lib/_gambc.c @SETDLPATH@ $(rootfromhere)/gsc-comp -:=$(srcdirpfx)$(rootfromhere) -f -link -l $(srcdirpfx)$(rootfromhere)/lib/_gambc -o $@ $(LIBRARY_MODULES_C) @@ -182,6 +189,11 @@ $(INSTALL_DATA) $(srcdirpfx)_gambcgsc.c $(libdir)/_gambcgsc.c @MAKE_LIBRARY_FOR_INSTALL@ $(INSTALL_LIB) $(LIBRARY) $(libdir)/$(LIBRARY) + if test $(GAMBCLIB) = $(LIB_VERSION); then \ + cd $(libdir); \ + ln -sf $(GAMBCGSCLIB) $(LIB_SONAME); \ + ln -sf $(LIB_SONAME) libgambcgsc.so; \ + fi @FIXLIB@ $(libdir)/$(LIBRARY) #for library in $(LIBRARIES_SCM); do \ # $(INSTALL_DATA) $$library $(libdir)/$$library; \ @@ -193,6 +205,8 @@ uninstall-post: rm -f $(bindir)/$(EXECUTABLE) + rm -f $(libdir)/$(LIB_SONAME) + rm -f $(libdir)/libgambcgsc.so mostlyclean-pre: diff -urNad gambc~/gsi/makefile.in gambc/gsi/makefile.in --- gambc~/gsi/makefile.in 2008-06-04 18:20:15.000000000 -0400 +++ gambc/gsi/makefile.in 2008-06-04 18:20:42.000000000 -0400 @@ -30,8 +30,10 @@ LIBS = @LIBS@ GAMBCLIB = @GAMBCLIB@ +LIB_VERSION = @LIB_VERSION@ GAMBCGSCLIB = @GAMBCGSCLIB@ GAMBCGSILIB = @GAMBCGSILIB@ +LIB_SONAME = @GSI_LIB_SONAME@ INSTALL = @INSTALL@ INSTALL_DATA = @INSTALL_DATA@ INSTALL_LIB = @INSTALL_LIB@ @@ -166,6 +168,11 @@ $(INSTALL_DATA) $(srcdirpfx)_gambcgsi.c $(libdir)/_gambcgsi.c @MAKE_LIBRARY_FOR_INSTALL@ $(INSTALL_LIB) $(LIBRARY) $(libdir)/$(LIBRARY) + if test $(GAMBCLIB) = $(LIB_VERSION); then \ + cd $(libdir); \ + ln -sf $(GAMBCGSILIB) $(LIB_SONAME); \ + ln -sf $(LIB_SONAME) libgambcgsi.so; \ + fi @FIXLIB@ $(libdir)/$(LIBRARY) #for library in $(LIBRARIES_SCM); do \ # $(INSTALL_DATA) $$library $(libdir)/$$library; \ @@ -177,6 +184,8 @@ uninstall-post: rm -f $(bindir)/$(EXECUTABLE) + rm -f $(libdir)/$(LIB_SONAME) + rm -f $(libdir)/libgambcgsi.so mostlyclean-pre: diff -urNad gambc~/lib/makefile.in gambc/lib/makefile.in --- gambc~/lib/makefile.in 2008-06-04 18:20:15.000000000 -0400 +++ gambc/lib/makefile.in 2008-06-04 18:20:17.000000000 -0400 @@ -30,6 +30,8 @@ LIBS = @LIBS@ GAMBCLIB = @GAMBCLIB@ +LIB_VERSION = @LIB_VERSION@ +LIB_SONAME = @LIB_SONAME@ GAMBCCOMPLIB = @GAMBCCOMPLIB@ INSTALL = @INSTALL@ INSTALL_DATA = @INSTALL_DATA@ @@ -117,6 +119,11 @@ $(LIBRARY): $(LIBRARY_OBJECTS_IN_COMPILE_ORDER) rm -f $(LIBRARY) @MAKE_LIBRARY@ + # needed for bootstrap: + if test $(GAMBCLIB) = $(LIB_VERSION); then \ + ln -sf $(GAMBCLIB) $(LIB_SONAME); \ + ln -sf $(LIB_SONAME) libgambc.so; \ + fi _gambc.c: $(MODULES_C) @SETDLPATH@ $(rootfromhere)/gsc-comp -:=$(srcdirpfx)$(rootfromhere) -f -link -flat -o _gambc.c $(MODULES_C) @@ -166,6 +173,11 @@ $(srcdirpfx)$(rootfromhere)/mkidirs $(libdir) $(INSTALL_DATA) $(srcdirpfx)_gambc.c $(libdir)/_gambc.c $(INSTALL_LIB) $(LIBRARY) $(libdir)/$(LIBRARY) + if test $(GAMBCLIB) = $(LIB_VERSION); then \ + cd $(libdir); \ + ln -sf $(GAMBCLIB) $(LIB_SONAME); \ + ln -sf $(LIB_SONAME) libgambc.so; \ + fi @FIXLIB@ $(libdir)/$(LIBRARY) for library in $(LIBRARIES_SCM); do \ $(INSTALL_DATA) $$library $(libdir)/$$library; \ @@ -176,6 +188,8 @@ uninstall-post: rm -f $(libdir)/_gambc.c rm -f $(libdir)/$(LIBRARY) + rm -f $(libdir)/$(LIB_SONAME) + rm -f $(libdir)/libgambc.so @for library in $(LIBRARIES_SCM); do \ rm -f $(libdir)/$$library; \ done ================================ It would be nice if this could be configured without requiring a bootstrap: #!/bin/sh /usr/share/dpatch/dpatch-run ## 99_move_base_link_file.dpatch by "Kurt B. Kaiser" <kbk@shore.net> ## ## DP: Find the compiler's base link file in lib/gambc4 instead of lib/ so ## DP: the user doesn't have to specify the path. It would be best if ## DP: this wasn't hard coded in Gambit-C. @DPATCH@ diff -urNad gambc~/gsc/_gsclib.scm gambc/gsc/_gsclib.scm --- gambc~/gsc/_gsclib.scm 2008-03-10 12:22:50.000000000 -0400 +++ gambc/gsc/_gsclib.scm 2008-06-05 09:20:01.000000000 -0400 @@ -244,7 +244,7 @@ (let ((gambcdir-lib (parameterize ((##current-directory - (##path-expand "lib" (##path-expand "~~")))) + (##path-expand "lib/gambc4" (##path-expand "~~")))) (##current-directory)))) (##string-append gambcdir-lib "_gambc")) (macro-force-vars (base)
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.
Adrien Pierard <pierarda@iro.umontreal.ca> writes:
The package installation system on Debian doesn't touch /usr/local/.
BSDs install all third party software in /usr/local
Not at all. We (pkgsrc, NetBSD) install all third party software in /usr/pkg on all BSDs and not only on BSDs (Solaris, HP-UX &c). But I agree with you, the world is more diverse.
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.
Sure.
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.
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.
BTW, speaking of installation improvements. Could you: 1. Rename "bin/scheme-r5rs" to anything more meaningful and different, this conflicts with Scheme48 and isn't distinguishable from any other Scheme. Same for other variants. 2. Not remove anything at installation time, see the diff against 4.2.8: --- makefile.in.orig 2008-05-17 08:43:44.000000000 -0400 +++ makefile.in @@ -174,10 +174,10 @@ publish-release: fake_target install-pre: install-post: all - rm -f $(prefix)/current $(prefix)/current.lnk - if test "@bat@" = ""; then \ - (cd $(prefix) && $(LN_S) .$(PACKAGE_SUBDIR) current); \ - fi +# rm -f $(prefix)/current $(prefix)/current.lnk +# if test "@bat@" = ""; then \ +# (cd $(prefix) && $(LN_S) .$(PACKAGE_SUBDIR) current); \ +# fi uninstall-pre: -- HE CE3OH...
participants (4)
-
Adrien Pierard -
Aleksej Saushev -
Christian Jaeger -
Kurt B. Kaiser