scsh-hackers
[Top] [All Lists]

Re: [Scsh-hackers] Proposal for packaging of scsh libraries

To: Michel Schinz <Michel.Schinz@epfl.ch>
Subject: Re: [Scsh-hackers] Proposal for packaging of scsh libraries
From: Martin Gasbichler <gasbichl@informatik.uni-tuebingen.de>
Date: Wed Nov 19 07:40:03 2003
Cc: scsh-hackers <scsh-hackers@lists.sourceforge.net>
List-id: Discussion among the implementors <scsh-hackers.lists.sourceforge.net>
Sender: scsh-hackers-admin@lists.sourceforge.net
Michel Schinz <Michel.Schinz@epfl.ch> writes:

> Andreas Bernauer <andreas.bernauer@gmx.de> writes:
>
>> Michel Schinz wrote:
>>> I have another suggestion which goes a bit in your direction: we could
>>> say that "-ll" can also be given the name of a *directory* as
>>> argument. In that case, it would look for a file, say "packages.scm"
>>> in that directory. A bit like HTTP servers look for "index.html" when
>>> the client requests a directory. 
>>
>> Just in case we are voting about this issue, too: I vote for this!
>> This will be very useful in my opinion, as symlinked packages.scm
>> don't work.
>
> Indeed, that's also something I found out while performing some
> experiments related to know how to organise packages.

We can think about this later. For now I would like to keep scsh's
implementation separate from the packaging proposal.

> I think, by the way, that scsh/scheme48 should be "fixed" so that it
> chases symbolic links when loading files, and interprets relative file
> names relatively to the location of the target of the symbolic link,
> and not at the location of the link itself, as it does now.

The problem here is that the S48 module system tries to be platform
independant. It therefore does only simple text-based interpretation
of file names but does not know how to resolve links or relative
paths. I agree that this should be changed but it is unclear to me how
to solve this in a nice, portable way.

--
Martin


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