scsh-hackers
[Top] [All Lists]

[Scsh-hackers] Packaging proposal: C-Code problems

To: scsh-hackers@lists.sourceforge.net
Subject: [Scsh-hackers] Packaging proposal: C-Code problems
From: David Frese <dfrese@dfrese.de>
Date: Wed Dec 17 06:10:01 2003
List-id: Discussion among the implementors <scsh-hackers.lists.sourceforge.net>
Sender: scsh-hackers-admin@lists.sourceforge.net
Hi,

some more little problems have occurred as I'm working on the
package-definition of SCX:

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...

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
time.

Any ideas for that... I don't have good ones:

For 1) I can only think of either

  - some runtime-support for libraries or

  - changing the installed load.scm according to the layout, e.g. if
  it has a platform-directory or not, and how it looks like (by the
  way: one cannot specify a layout like scsh on the command-line, can
  one?)

  - making load.scm platform depend

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.

So maybe the install-prefix should be prepended to the other prefix,
and not be a replacement for it...

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...

--
David


<Prev in Thread] Current Thread [Next in Thread>