defmod fails to build

[Stewart Brodie]

In message <bb954b864a.Tony at mk-net.demon.co.uk> you wrote:

> On 5 Jun 2001, Stewart Brodie <stewart.brodie at pace.co.uk> wrote:
> 
> > Please could somebody tell me where error_ESCAPE and error_STK_OFLO are
> > defined?  I've searched all the archives I've downloaded and I can't find
> > it.
> > 
> They're both defined in core.oslib.h.os. This is probably not correct, as
> this header is itself generated by DefMod, so it won't work on a clean
> build. They ought to be defined elsewhere for a DefMod build. I'll give
> that some thought.

:-)  I think half my problem was that I didn't even know what they were
supposed to be.  I think in the end I guessed that there were error numbers,
so I defined error_ESCAPE as SIGINT and error_STK_OFLO as 1025 (out of the
way of other signal numbers)


> > If anybody's interested, I built OSLib on our dual-processor FreeBSD box
> > (2 x P3-500) today with my new portable version of defmod: it built the
> > object code, complete set of C header and complete set of assembler
> > headers in 1 minute 9 seconds.  I hope to get this down under a minute
> > when we put it on our new build machine. :-)
> > 
> Sounds useful. Would you like to send me the diffs, so that I can make a
> public release?

I'd like to get it working from clean first :-)  I've only actually changed
defmod and the parts of SWILib it needs (because that's the only bit we need
here).  I'll write some brief instructions for it too.  What I'll probably do
is supply the cross-compilation scripts for it that I've got in our CVS
repository - I actually have a RISC OS-compatible directory structure in the
repository and have a build directory in which I generate a directory full of
softlinks to the original sources so I don't get out of step between the
different versions.  This may sound hacky, but a lot of our tools are done
this way so we can cross-compile them and build UNIX versions etc.

Hopefully I'll have it ready for review at least here by the end of the week.

> > The new implementation of cstrong.c in the latest defmod is a real
> > problem because it uses the exception library :-(

> It's used by other modules as well, but probably not as extensively. I
> don't think DefMod was ever intended to be particularly portable (Jonathan
> will probably correct me), using RISC OS calls as necessary, so I consider
> it  quite an achievement that you have accomplished it in any case. 

> Why is the exception libray a problem, Stewart? I think it's all legal C.
> Presumably you've had to port MessageTrans and its friends in any case.

It could be that I'm taking the wrong approach.  I'm trying to simulate the
SIGOSERROR behaviour.  I've implemented the two "SWIs" that defmod needs as
functions that have x and non-x variations.  The non-x variation calls the x
variation and if an error is returned, stores the error pointer in a global
variable (returned by my new _kernel_last_oserror implementation) and raises
SIGOSERROR (which I define to be SIGUSR2)

All my changes are protected by #ifdef markers.  There are three macros that
my RISC OS builds now use, two that a public OSLib would use:

RISCOS               (we are building defmod on RISC OS)
EXECUTE_ON_RISCOS    (we are going to run this defmod on RISC OS)
PACE_BUILD           (take version information from our VersionNum file
                      instead of __DATE__)

You need the two top ones so that you can distinguish between building a
defmod to run on the same platform that you are compiling it on, and
cross-compile defmod to generate an AIF image on a non-RISC OS platform (e.g.
compile it with ADS).  RISCOS implies EXECUTE_ON_RISCOS (but you need to
specify both)

The SWILib header files now have #ifdef EXECUTE_ON_RISCOS wrapping the SWI
#defines and function declarations in the else clause - although I only
needed 4 functions in total I think.

I've added a nearly empty kernel.h (declares _kernel_oserror and
_kernel_last_error()) , an empty swis.h, and a copy of riscos.c called unix.c
that contained the UNIX implementations of the SWIs required.

The internationalised errors were easy - I just return the defaults.  Errors
cannot be parameterised - I couldn't bothered to re-implement the
substitutions properly, but could be persuaded when I'm not so pressed for
time.

I replaced the (very inefficient!) reading of files byte-by-byte by standard
library calls to fopen/getc/feof/ferror/fclose.  This will speed up execution
on RISC OS a lot if you take my implementation, but I've kept the original
for now when EXECUTE_ON_RISCOS is set.


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