OSLib cvs repository

Jonathan Coxhead jonathan at doves.demon.co.uk
Mon Jun 17 22:30:19 BST 2002


    On 17 Jun 2002, at 19:12, Tom Hughes wrote:

> That line is there, but I that just tells it which extensions to process
> implicit rules for - as far as I know amu will still look for swi.XXX rather
> than XXX/swi when it wants to find a source file from which to build a given
> target.

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

   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.

   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.

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

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

   I can't see this repository yet---I'll have another go soon.

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



More information about the oslib-team mailing list