OSLib 6.11 Released

[Chris Rutter]

On Tue, 26 Sep 2000, Jonathan Coxhead wrote:

>    #include is relative to the file that contains the line (in ANSI C). The 
> K&R rule was different, but not often seen now.

Oh, okay, I thought so.

>    I think this is another vote for putting a "/" in the #include directive
> ---would you be happy writing
> 
>       #include "oslib/foo.h"
> 
> and compiling with -IOSLib:?

Certainly, though for my code, where I only ever forsee included on
RISC OS, the old method of defining OSLibInclude$Path will still work,
so I'm happy anyway. :-)

This problem is soluble.  I think:

  * You cannot ever introduce any ambiguity into the system: and this
    includes the chance of a namespace clash.  The standard directory
    prefixes that have evolved from UNIX systems and their derivatives
    are well-known and prove an exception to this rule.

  * `core', `computer' and `user' are too ambiguous: they cannot be a
    top-level prefix.

  * Selecting another top-level prefix, such as `oslib', is reasonable,
    and poses no more namespace clash than `glib', `mLib', or whatever;
    furthermore, you can place it on the system include path only, so
    as not to clash with your local projects.

  * This however means that one must include things like "oslib/core/foo.h";
    people are bound to dislike this.  Thus either:

      - insist upon filesystems that can cope with over 77 files -- with
        the free availability of raFS, and the fact that development systems
        will tend to be recent, and that OSLib isn't backward-compatible
        with older versions people may be using on (say) RISC OS 2/3 machines,
        this is reasonable: then destroy the subdirectories;

      - move all the header files into an `oslib' subdirectory within their
        `core', `computer', `user' or `toolbox' directory, and include all
        of those in your search path.

Is there any other alternative?

c.