OSLib 6.11 Released

[Stewart Brodie]

In message <912W1gAKnH05EwpV at mk-net.demon.co.uk>
          Tony van der Hoff <OSLib at mk-net.demon.co.uk> wrote:

> 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 ;-) 

Filename collisions will always occur due to the nature of what OSLib is. 
"wimp.h" is the classic problem - there is hardly a RISC OS library out there
that doesn't feature a wimp.h.  However, that is the *application's* problem
and not the library.  The include file search rules will look after
inter-library inclusion.


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

A file oslib.c containing just: #include "OSLib:osfscontrol.h" causes:

% armcc -c oslib.c
"oslib.c", line 2: Serious error: #include file "OSLib:osfscontrol.h" wouldn't open.

This is because, obviously, Solaris cannot find the file.  


(Yes, I know it says line 2 - that's a complication caused by an improvement
I made a long time ago to make the compiler generate preprocessed output that
our McCabe tools can handle.)

> 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 do quite a bit of cross-platform work nowadays simply for the speed of the
build.  We have a very fast central server that can compile stuff "virtually
instantly".

Paths are a major problem for building stuff on non-RISC OS hosts, albeit not
the only one (Environmental variables created with SetMacro being the other
major one).  I haven't found a library that will resolve paths.  I did look
at FreeBSD's man source to see how it found manual pages on MANPATH. 
Disappointingly, it simply getenv'ed it and used strchr et al to parse it
manually.  I have written a perl script which I called findonpath which also
solves the SetMacro problem, but it's very hacky and can only be used in a
Makefile using backticks.

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

I think people overestimate the impact of file length on compilation time. 
Anything that includes anything from OSLib incurs a major hit.  Usage of
"#pragma include_only_once" would probably help far more.

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

If it was decided that this is the way to go, then I think we'd all want to
think about it before implementation.  You need not have to implement this
yourself.

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

There's a big difference between putting the full pathname to the file in
there (which is what using OSLib: does) and using a relative pathname to the
root of the OSLib installation.  e.g.  "Core/types.h", "Computer/wimp.h".

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

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

If you want to avoid using the path in the #include statements, then you
should fallback to requiring people to use multiple -I arguments to the
compiler.  This is the way it works on other platforms!  Alternatively, you
could have RISC OS-specific install targets that do the multiple directory
stuff, and non-RISC OS targets that shove everything into a single directory.

One possibility that would probably suit only me personally would be to
commit to a specific release of OSLib and simply rearrange it all by hand and
never use a later version.  In effect, that is the current position here -
we're using OSLib 4.something and have no need to upgrade as very little of
our source code uses OSLib.

-- 
Stewart Brodie, Senior Software Engineer    (Views expressed are my own and
Pace Micro Technology PLC                   not those of my employer)
645 Newmarket Road
Cambridge, CB5 8PB, United Kingdom         WWW: http://www.pacemicro.com/