__RISCOSIFY_STRICT_UNIX_SPECS

Alex Waugh alex at alexwaugh.com
Thu Jan 13 13:12:09 PST 2005


In message <bb51562c4d.Jo at hobbes.bass-software.com>
          John Tytgat <John.Tytgat at aaug.net> wrote:

> In message <6c3c482b4d.ajw498 at caramel.cp15.org>
>           Alex Waugh <alex at alexwaugh.com> wrote:
> 
> > [...]
> Uh, then I guess you're dealing with the same issues as in my CVS port.
> Support you checkout a file from a remote repository having a ':' in its
> (Unix) name. What happens ? My experience is that if you don't have a
> bijective mapping from Unix specs to RISC OS specs and back, that you have
> hairy issues.  The more RISC OS features (like paths) you're allowing in
> your Unix specs (and still with their RISC OS semantics), the more hairy
> the situation gets.

Subversion is stricter about what characters are allowed in filenames
than CVS, but there are probably still character that would cause
issues. Some sort of escaping may be a good idea.

> > however it was being linked to an ssh library which
> > had filenames such as Choices:Crypto.PuTTY.sshknownhosts
> > hardcoded. It would be trivial to change these hardcoded filenames, but
> > I was expecting riscosify to be able to cope with them.
> 
> I'm not sure I'm sharing the same expectation.

Now I know the intention of __RISCOSIFY_STRICT_UNIX_SPECS, I'm not
sure that I expect it either. But I think it should be changed to
either allow this form of RISC OS filename, or to disallow other forms
of RISC OS filenames.

> This makes me thinking and I see the following problem when we're
> going to move to using more sharable modules : each module might have
> its own preference or even requirement for its filepath translations.
> This could mean we have to go for one __riscosify_control value for
> all sharable modules.  Thoughts ?

I can't think of an easy solution to this.

Alex

-- 
Alex Waugh                                           alex at alexwaugh.com

PHP, Roots, Subversion, WebJames and more from http://www.alexwaugh.com/



More information about the gcc mailing list