riscosify and /home/riscos/env/
theo at markettos.org.uk
Wed Jun 15 07:13:43 PDT 2005
On Wed, Jun 15, 2005 at 01:07:17AM +0200, John Tytgat wrote:
> Did you also made changes so that __unixify() on foo:bar results in
> /home/riscos/env/foo/bar (i.e. the reverse translation) ?
No, is this necessary? Under this scheme there's not a 1:1 mapping between
riscosify and unixify because if asked to unixify a path mem:foo how do I
know whether mem: is a RISC OS path variable or a filing system? At the
moment this gets unixified into /mem:foo/ IMO it would be a bit surprising
to have this translated to /home/riscos/env/mem/foo/ if you didn't ask for
There are two issues here. Firstly it is this unixified value is what will
be used when the program prints something under RISC OS. Having
/home/riscos/.../ might confuse the user somewhat. Secondly this path is
what will be used in the cross compile process if you want to do
--prefix=myapp: but Makefiles etc will cause trouble due to the colon.
I suppose we could say that /mem:foo/ was fairly useless as a Unix
path and we ought to make it something that has a chance of working when
cross compiling. But I don't think this is that necessary, and to usurp the
default mapping of "/mem:"=unixify("mem:") would break the principle of
> I don't think it will be an issue for your patch but have a look at
> the source/unix/dirent.c if those routines keep on working with e.g.
> /home/riscos/env/foo/bar as opendir() argument (assuming bar is a dir).
I can't see a problem looking at the code, and the regression test (thanks
Alex for pointing them out!) tst-seekdir works as expected. In this case
it's just another way of representing /foo:bar/ that we had before and
there's nothing that uses the unix name before it gets riscosified.
More information about the gcc