OSLib 6.11 Released

[Tony van der Hoff]

On Wed, 27 Sep 2000, at 11:28:16, Jonathan Coxhead
<jonathan at doves.demon.co.uk> wrote on the subject "OSLib 6.11 Released":

>   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.
>
Ah, yes, I like it, so far. 

Presumably the o.OSLib goes at the top OSLib level. Then there's types.h
and macros.h. Does this look sensible (in addition top the above
structure):

$
  OSLib
    setpaths
    docs
      ...
    o
      OSLib
    types
      oslib
        h
          types
    macros
      oslib
        h
          macros
 

>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.
>
Maybe not pertinent to the present discussion, but a while ago I had to
abandon OS$Path for being too common, or something. OSLibInclude$Path
was an unnecessary excursion into silliness on my part at that time.
Although the latter is still defined, for practical purposes the whole
lot was subsumed into the single variable OSLib$Path. 

>   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
>
Well, say the top-level OSLib directory is called <OSLib$Dir> . Then the
default OSLib$Path would be defined as:

<OSLib$Dir>.,
<OSLib$Dir>.types.,
<OSLib$Dir>.macros.,
<OSLib$Dir>.core.,
<OSLib$Dir>.computer.,
<OSLib$Dir>.user.,
<OSLib$Dir>.toolbox.,
<OSLib$Dir>.types.oslib.,
<OSLib$Dir>.macros.oslib.
<OSLib$Dir>.core.oslib.,
<OSLib$Dir>.computer.oslib.,
<OSLib$Dir>.user.oslib.,
<OSLib$Dir>.toolbox.oslib.

Quite a handful, but still manageable, except under RO2, but I think we
can safely ignore that.


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


On Thu, 28 Sep 2000, at 03:05:21, Chris Rutter
<chris at willow.armlinux.org> wrote on the subject "OSLib 6.11 Released":

>The library should always, /always/ use relative paths, in my opinion.
>This is impervious to failure due to the user's include path configuration.
>If it does, the library's own #includes needn't be worried about, whatever
>the case.
>
There is, IMHO, some merit in this. The downside is that it's very
sensitive to changes in directory structure. I am concerned about
building the library with such inflexibility, and on balance would
prefer abstraction through path names. I'll return to this point later.

On Thu, 28 Sep 2000, at 03:16:32, Chris Rutter
<chris at willow.armlinux.org> wrote on the subject "OSLib 6.11 Released":
>
>Only that I think I prefer the merge-into-one-directory solution.
>
>The namespace of unqualified headers is clean (i.e. there won't be files
>`Computer' clashing with those in `Core'), so this is feasible.
>
>The fact that this isn't especially necessary -- we have a non-clashing
>namespace defined for us by RISC OS right from the start, anyway --
>suggests to me that in fact the headers /should not/ be segregated.
>
Well, I remain convinced that imposing a requirement for a third-party
FS on users is somewhat arrogant, even Gatesian. I'm afraid our users do
range from the totally clueless to the (two?) gurus who want to cross-
develop. The current discussion is primarily for the benefit of those
two. This is right and proper, but it is too easy to forget those users
who have no voice on this forum. 

Imposing a 3rd party FS (or even a soft-load Acorn FS) would certainly
create support problems, which I really don't need. I therefore believe
that until RO3 is no longer in common use we need to assume that there
is a limit of 77 files per directory, with 10 character file names.

Now, the source tree does not look anything like the release in terms of
directory structure. The release archive is built from scratch by
copying the files into it automatically by Obey files. Provided that the
library object and headers are unaffected, there is, I think, no reason
why I should not create a second release archive with a flatter
directory structure:

OSLib
  setpaths
  docs
    ...
  h
    types
    macros
    os
    ... 
  o 
    oslib

For maintenance purposes I would specifically *not* want to create a
different library build, so the internal #includes would have to be of
the common form oslib/os.h, not relative names. The default OSLib$Path
variable would be different for each environment, but this could be
easily accommodated. For the RO4 environment the path would simply be
<OSLib$Dir>.

The user can then just choose to download whichever archive is
appropriate to his environment. Those with an extended FS can choose the
flatter version; those wedded to RO3 can choose the legacy version. I
would almost certainly use the flatter version myself. Is it possible
that that would please everyone?


On Thu, 28 Sep 2000, at 04:26:20, David Bryan
<D.J.Bryan at cranfield.ac.uk> wrote on the subject "OSLib 6.11 Released":
>
>The only reason I even suggested this was: If you have
>"oslib/os.h" in the library header files, and the user wants to
>carry on using "wimp.h", the search path has got to have all the
>directories both with and without the final "oslib".  This is only
>likely to cause more emails to Tony.  "I've put all six
>directories on the search path, and it doesn't work."  The answer
>being, "Well, you now need twelve."
>
Thirteen, actually :-) Yes, it is a mess, but if we provide the default
path with them all in there, and somebody takes it into their head to
break it, they're just as likely to do it with six as with 13. I can use
one of my more abrasive replies to such e-mails ;-)


-- 
Tony van der Hoff         |  mailto:OSLib at mk-net.demon.co.uk
Buckinghamshire, England  |  http://www.mk-net.demon.co.uk/oslib/
----------------------------------------------------------------