OSLib cvs repository

[Tom Hughes]

In message <20020617212508$1d44 at gosford.compton.nu>
          "Jonathan Coxhead" <jonathan at doves.demon.co.uk> wrote:

>    It does more than that: the C run-time library has code to transpose c
> and h  directory names, so that this is done uniformly for all clients. By
> default, is  is only done for ".c", ".h" and ".s". (This is how the
> compiler knows to open  "h.fred" when you write "#include "fred.h"" in your
> C file.)

I thought that code was in the tools themselves rather than in the C library
code. I didn't realise that the Shared C Library had any such code in it i
fact, although I know UnixLib does.

>    When AMU sees a .SUFFIXES line, it adds the suffixes it sees to that
> list,  using the C library call provided for that purpose. So, within AMU
> at least,  the behaviour should be right. This was all done so that UNIX
> makefiles would  work on Acorn systems without needing enormous amounts of
> work, and that's  exactly what we are trying to do here.

I wasn't aware that there was any such library call... It must be an
undocumented entry point, but I don't recall there being many of those.

It's never really been possible to use unix makefiles with amu anyway
because it implemented such a restricted subset of the functionality of
the average unix make, and was full of bugs.

>    The above should all work providing that C files are referred to
> consistently within the makefile as "xxx.c", headers as "xxx.h", and SWI
> files  as "xxx.swi". My guess is that there is a culprit "swi.xxx"
> somewhere. This  will work fine on the Acorn machine, but fail under UNIX.
> In the form  "xxx.swi", it should work the same under both.

The makefile is written in the swi.xxx form, although there are no
actualy swi.xxx entries - there are targets of the form h.xxx and an
implicit rule of the .swi.h form to handle the conversion/

I'm running it on the Acorn machine anyway.

>    Is that the case? Also, maybe there are dynamic dependencies present in
> the  makefile, having the same effect?

There are no dynamic dependencies.

> > At the moment all I get (with both amu 5.02 and amu 5.16) is this:
> > 
> >   Making ADFS::Compton.$.Temporary.!OsLib.Source.Core.oslib ...
> >   AMU: Don't know how to make 'h.territory'
> >   AMU: *** 'core' not re-made because of errors ***
> > 
> > Because it is looking for swi.Territory to make it from, and that is the
> > name it has always had in the past, but in CVS Tony has changed all the
> > names so that file is now Territory/swi.
> 
>    (I hope you mean Territory.swi in a UNIX environment?)

Yes. I checked it out on unix (so it checked out as Territory.swi) and
then copied the checked out tree to RISC OS over an NFS mount which made
the file into Territory/swi on the RISC OS side.

I'm just wondering whether Tony though he had checked these files in
as swi.Territory but the RISC OS CVS client checked them in under the
more unix like name of Territory.swi, which I believe it will do if you
configure it to treat swi as a file extension.

Tom

-- 
Tom Hughes (tom at compton.nu)
http://www.compton.nu/