OSLib 6.11 Released

[Jonathan Coxhead]

On 27 Sep 00,, Tony van der Hoff wrote,

 | I have explained my unease about adopting raFS and X-files above. 

   Oh, O K, I thought that was your suggestion. Let's assume we don't do 
that then.

   Chris wrote ...

 | >      - 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.

   Now that's a solution I hadn't thought of, and I think I like it best.

   Tony wrote ...

 | This is, effectively the present situation. 

   No, the present situation is the "other way up". What Chris suggests is 
the following:

      $
         OSLib
            Core
               oslib
                 h
                    os
                    osbyte
                    ...
            Computer
               oslib
                  h
                     osfind
                     osfile
                     ...
            User
               oslib
                  h
                     wimp
                     drawfile
                     ...
            Toolbox
               oslib
                  keyboardshortcut
                  toolbox
                  window

   This is good, as it keeps the interface clean: there is 1 reserved name
---"oslib"---that appears in source code:

      #include "oslib/os.h"
      etc.

Everything inside that name we can play with, with no risk of collision. 
You don't have to know which of the magic 4 groups your header file lives 
in. We define OSLibInclude$Path to be 
"OS:Core,OS:Computer,OS:User,OS:Toolbox" (assuming OS$Path is 
ADFS::4.$.OSLib or something like that), and the instructions are to 
compile with

      -IOSLibInclude:

just as at present.

   People who want to use the current system with no "oslib/" prefix can do 
so too, by defining OSLibInclude$Path as 
OS:Core.oslib,OS:Computer.oslib,OS:User.oslib,OS:Toolbox.oslib. If you you 
want to mix & match (say, because you've just got a new version of OSLib 
that uses #include "oslib/os.h" internally, but you don't want to edit all 
your source files which contain #include "os.h"-style lines), then you 
define OSLibInclude$Path as
 
OS:Core,OS:Computer,OS:User,OS:Toolbox,OS:Core.oslib,OS:Computer.oslib,OS:Us
er.oslib,OS:Toolbox.oslib

and I suggest that we ship that with the release, so people with simple 
needs get the right effect "out of the box". We can assume that people 
doing complicated tasks like cross-compiling can change the variable to 
suit their needs.

   That seems very nice all round. Any downside?

 | >Is there any other alternative?

   Looks to me like we don't need one!

        /|
 o o o (_|/
        /|
       (_/