OSLib 6.11 Released

[Tony van der Hoff]

On Mon, 25 Sep 2000, at 17:52:00, David J. Ruck <druck at freeuk.com> wrote
on the subject "OSLib 6.11 Released":

>On 21 Sep 2000 Tony van der Hoff <OSLib at mk-net.demon.co.uk> wrote:
>> OSLib Version 6.11 - Tony van der Hoff - 19/09/2000
>[Snip]
>> *  All #includes in the library headers now specify the OSLib: library
>> path to  avoid possible name clashes with other libraries.
>
>This has caused considerable hassle for those of use who are building RISC OS
>applications on other platorms (either to use superior debugging tools or
>to build with cross compilers which aren't currently available for RISC OS).
>
Well, that just goes to show how you can't please all of the people all
of the time :-(

This scheme was introduced in response to a considerable number (well,
about 8) of reports from individuals who experienced file name
collisions. So far, I've seen 3 objections to it, one of which was
subsequently withdrawn, so I guess we're still winning ;-) 

On Mon, 25 Sep 2000, at 18:20:36, Stewart Brodie
<stewart.brodie at pace.co.uk> wrote on the subject "OSLib 6.11 Released":
>
><AOL>Me too!</AOL>
>
I'd be interested to learn what exact problems you are experiencing,
Stewart.

The scheme works well under RISC-OS, with the main-stream compilers
available for the platform, but until now, I wasn't aware of anyone
doing cross-platform development, so I never took it into account. I
guess that's not the point, and I do want to satisfy as many users as I
can.

I suppose I could (should?) have wrapped the new form in a conditional:

#ifndef types_H
  #if !defined OSLIB_NOPATH
    #include "OSLib:types.h"
  #else
    #include "types.h"
  #endif
#endif
 
That's a fairly easy change to make to DefMod. The drawback is, of
course, that you'd lose the benefit of the path name, but you'd be no
worse off than before. It also lengthens the headers, thus compile time,
a bit, but would it suit your purpose, Dave and Stewart? 

On Mon, 25 Sep 2000, at 14:04:50, Jonathan Coxhead
<jonathan at doves.demon.co.uk> wrote on the subject "OSLib 6.11 Released":
>
>   I'm not sure I like it either---it seems like it crosses some 
>abstraction barrier that it shouldn't.
>
Could you explain that a bit more, please, Jonathan?

To me, it seems like an elegant solution to a problem that affected a
number of people, including myself. It has worked fine while I've been
using it.
>
>   As far as I can see, the best way to decrease the chance of collision 
>with other headers is to use the already-existing division of OSLib into 4 
>functional units: Core, Computer, User, Toolbox. 

Whereas the path name scheme was a simple change to DefMod, your
proposal would require manual changes to each and every module, at least
a day's tedious work, which at present I am neither prepared nor able to
expend. There may be a way of automating it, but I can't think of a
practical one right now. 

Even putting that aside, those divisions are not natural, imposed by the
77 files per directory limit, and are, to some extent, arbitrary. They
are currently totally flexible, only determined by environment
variables. I wouldn't want to promote them into the body of the code.

Possibly a nicer solution, but which would only work on filing systems
which allow unlimited files per directory, might be to do away with the
division, put all the headers together in a single directory, and
include that in the file name. That would probably mean distributing X-
files or ra-FS with OSLib, and requiring a module installation.
>
>   I think that's completely portable to all platforms, and reduces the 
>chance of a collision to damn close to 0. Am I right?
>
I don't know how GCC would handle the mapping, but on the assumption
that it's similar to Norcroft, yes, of course you're right. However, the
benefit that your scheme bestows over using the path name (with the
compile-time switch) is, I think, minimal, and it has the two drawbacks
enumerated above. 

Unless it's the only way forward, I'd rather avoid it.
-- 
Tony van der Hoff         |  mailto:OSLib at mk-net.demon.co.uk
Buckinghamshire, England  |  http://www.mk-net.demon.co.uk/oslib/
----------------------------------------------------------------