scsh-hackers
[Top] [All Lists]

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

To: Michel Schinz <Michel.Schinz@epfl.ch>
Subject: Re: [Scsh-hackers] Packaging proposal: C-Code problems
From: David Frese <dfrese@dfrese.de>
Date: Wed Dec 17 13:34:04 2003
Cc: scsh-hackers@lists.sourceforge.net
List-id: Discussion among the implementors <scsh-hackers.lists.sourceforge.net>
Sender: scsh-hackers-admin@lists.sourceforge.net
Am Wed, 17 Dec 2003 21:10:22 +0100 schrieb Michel Schinz (== "Michel"):

Michel> Le 17 déc. 03, à 15:08, David Frese a écrit :
>> Hi,

Michel> To be more precise, we would have a location called "lib-base" as you
Michel> suggest (although we could also keep the current "lib") and this
Michel> location would *always* contain one sub-directory per
Michel> platform. Nothing should be installed in the "lib-base" location
Michel> directly.

Michel> I don't think this conflicts in any way with the FHS.

Michel> As you say, this means that for now packages with a platform-dependent
Michel> "load.scm" file will need to install "configure.scm" along. This is
Michel> only a short-term annoyance, though, as temporary as "configure.scm"
Michel> is.

This would be OK. And the (host) function has to be available from
within the pkd-def.scm, to install the libs there (with 'make').


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

Michel> Yes, this has been on my to-do list for some time. I'm not really sure
Michel> about how I want to do it for now, though. A straightforward way to do
Michel> it would be to add an option to the script, say --non-shared-only, and
Michel> have all install-* procedures do nothing if this option is given and
Michel> the specified location is a shared one (i.e. something else than
Michel> "lib").

Michel> We should also have a way to know from the "pkg-def.scm" file whether
Michel> this option is active or not, for cases where the simple technique
Michel> above is not enough. Maybe.

Yes, that sounds good.

>> (by the way: one cannot specify a layout like scsh on the
>> command-line, can
>> one?)

[cut]

Michel> But maybe you're thinking about something else, in which case I'd be
Michel> happy to know what you have in mind.

No sorry, I didn't think of the tilde-expansion...

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

Michel> Yes, and in the mid-term the location of "scheme48.h" would be a very
Michel> nice thing to include in that famous package to access configuration
Michel> parameters we keep talking about.

Michel> But I'm not sure I understand how you want to include that in
Michel> "configure.scm" in the meantime.

Me neither... Martin said so.

But if it doesn't work, it could be another command-line-option. But
that option (and maybe others) should only be visible if the pkg-def
says something like 'has-libs or 'show-lib-options, because most
packages will be without libs i guess.

Or maybe one could implement a generalized way that allows the pkd-def
to declare more command-line options...


Michel> Thanks a lot for your comments, they really help making the
Michel> installation library and the proposal better.

No problem, I'm getting paid for it :-))

--
David


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