Le 17 déc. 03, à 15:08, David Frese a écrit :
1) the load.scm of SCX has to be able to find the right shared-objects
for all platforms, since it is in a platform-independ directory. So my
first idea was that we would need a 'lib-base directory and load.scm
would append the platform dynamically (configure.scm has to be
installed for that too). But then I saw that that does not work for
the fhs-layout, since it has no platform-directories...
Indeed, that's annoying. An easy (and IMO relatively clean) solution to
solve this problem is to change the FHS layout so that it contains a
platform-specific directory too.
To be more precise, we would have a location called "lib-base" as you
suggest (although we could also keep the current "lib") and this
location would *always* contain one sub-directory per platform. Nothing
should be installed in the "lib-base" location directly.
I don't think this conflicts in any way with the FHS.
As you say, this means that for now packages with a platform-dependent
"load.scm" file will need to install "configure.scm" along. This is
only a short-term annoyance, though, as temporary as "configure.scm"
2) closely related to that is the problem of installing SCX for
multiple platforms. The shared objects are of course the only files
that have to be installed multiple times, so it would be good if one
would skip the installation of platform-independent files the second
Yes, this has been on my to-do list for some time. I'm not really sure
about how I want to do it for now, though. A straightforward way to do
it would be to add an option to the script, say --non-shared-only, and
have all install-* procedures do nothing if this option is given and
the specified location is a shared one (i.e. something else than
We should also have a way to know from the "pkg-def.scm" file whether
this option is active or not, for cases where the simple technique
above is not enough. Maybe.
- changing the installed load.scm according to the layout, e.g. if
it has a platform-directory or not, and how it looks like
That would be an option, but I'd rather avoid it if we can. I'd like
the installation script to be completely independent of the selected
layout, if that's possible.
(by the way: one cannot specify a layout like scsh on the
Well, it depends what you mean exactly by this. As you have certainly
seen, a layout like "scsh" is not really a layout, but rather a layout
generator. That is, a function which, given a package name, a version
and a platform name, produces a layout.
Now, on the command line one can specify either a predefined layout
generator or a *constant* layout. Depending on how people end up using
this functionality (putting layouts directly on the command line), this
might be a problem or not. I thought that the main use for this feature
was that package installers (e.g. Fink's) could specify a layout suited
to their policies on the command line. And in that case, the fact that
one can only specify constant layout is no big deal as these installers
typically make it easy to insert the name or version of a package on
the command line, through percent expansion. For example, in a Fink
package you can use the string "%n" to represent the name of the
package being installed. This feature makes it easy to specify pseudo
layout generators, suited to several packages.
But I can foresee another use for custom layouts: if some administrator
or user decides that he likes none of the standard layouts we provide
with the library, he could decide to write his own. And then he would
need the ability to specify a layout generator, that is a complete
Scheme function. I think this could be useful, but not top priority.
But maybe you're thinking about something else, in which case I'd be
happy to know what you have in mind.
3) one should be able to configure the C-Code with the normal prefix
(as the code might want to use it) but installation should of course
go to the installation-dirs. As SCX uses Makefiles generated by
automake, and uses 'make install' to install the shared-objects one
could use the DESTDIR variable; that dir is prepended to the path for
every installed file. But that is not compatible with the current
--install-prefix thing. What 'automake' assumes is that with a prefix
of /usr and a install-prefix of /tmp the files go to
/tmp/usr/scx... and not to /tmp/scx... like it is now.
Ouch, yes, I had completely forgotten that DESTDIR works like that,
sorry. So I'll change the installation library so that
"--install-prefix" is a prefix of the prefix. I guess I'll rename this
option in the process, as "the prefix of the prefix" doesn't sound too
good. I'll see.
4) Another problem was that SCX needs to know where the scsh-include
files are (scheme48.h)... but Martin said that could go into
configure.scm. So thats not really a problem of the package proposal,
but every package with C-Code will need it...
Yes, and in the mid-term the location of "scheme48.h" would be a very
nice thing to include in that famous package to access configuration
parameters we keep talking about.
But I'm not sure I understand how you want to include that in
"configure.scm" in the meantime.
Thanks a lot for your comments, they really help making the
installation library and the proposal better.