libtiff/contrib/acorn
2004-06-05 09:02:03 +00:00
..
cleanlib Initial revision 1999-07-27 21:50:26 +00:00
convert Initial revision 1999-07-27 21:50:26 +00:00
install Initial revision 1999-07-27 21:50:26 +00:00
Makefile.acorn *** empty log message *** 2004-04-20 10:31:05 +00:00
Makefile.am *** empty log message *** 2004-05-19 18:28:57 +00:00
Makefile.in *** empty log message *** 2004-06-05 09:02:03 +00:00
ReadMe Initial revision 1999-07-27 21:50:26 +00:00
SetVars Initial revision 1999-07-27 21:50:26 +00:00

Building the Software on an Acorn RISC OS system

The directory contrib/acorn contains support for compiling the library under
Acorn C/C++ under Acorn's RISC OS 3.10 or above. Subsequent pathnames will
use the Acorn format: The full-stop or period character is a pathname
delimeter, and the slash character is not interpreted; the reverse position
from Unix. Thus "libtiff/tif_acorn.c" becomes "libtiff.tif_acorn/c".

This support was contributed by Peter Greenham.
(peterg@angmulti.demon.co.uk).

Installing LibTIFF:

LIBTIFF uses several files which have names longer than the normal RISC OS
maximum of ten characters. This complicates matters. Maybe one day Acorn will
address the problem and implement long filenames properly. Until then this
gets messy, especially as I'm trying to do this with obeyfiles and not have
to include binaries in this distribution.

First of all, ensure you have Truncate configured on (type *Configure
Truncate On) Although it is, of course, preferable to have long filenames,
LIBTIFF can be installed with short filenames, and it will compile and link
without problems. However, getting it there is more problematic.
contrib.acorn.install is an installation obeyfile which will create a normal
Acorn-style library from the source (ie: with c, h and o folders etc.), but
needs the distribution library to have been unpacked into a location which is
capable of supporting long filenames, even if only temporarily.

My recommendation, until Acorn address this problem properly, is to use Jason
Tribbeck's LongFilenames , or any other working system that gives you long
filenames, like a nearby NFS server for instance.

If you are using Longfilenames, even if only temporarily to install LIBTIFF,
unpack the TAR into a RAMDisc which has been longfilenamed (ie: *addlongfs
ram) and then install from there to the hard disk. Unfortunately
Longfilenames seems a bit unhappy about copying a bunch of long-named files
across the same filing system, but is happy going between systems. You'll
need to create a ramdisk of about 2Mb.

Now you can run the installation script I've supplied (in contrib.acorn),
which will automate the process of installing LIBTIFF as an Acorn-style
library. The syntax is as follows:

install <source_dir> <dest_dir>

Install will then create <dest_dir> and put the library in there. For
example, having used LongFilenames on the RAMDisk and unpacked the library
into there, you can then type:

Obey RAM::RamDisc0.$.contrib.acorn.install RAM::RamDisc0.$ ADFS::4.$.LIBTIFF

It doesn't matter if the destination location can cope with long filenames or
not. The filenames will be truncated if necessary (*Configure Truncate On if
you get errors) and all will be well.

Compiling LibTIFF:

Once the LibTIFF folder has been created and the files put inside, making the
library should be just a matter of running 'SetVars' to set the appropriate
system variables, then running 'Makefile'.

OSLib

OSLib is a comprehensive API for RISC OS machines, written by Jonathan
Coxhead of Acorn Computers (although OSLib is not an official Acorn product).
Using the OSLib SWI veneers produces code which is more compact and more
efficient than code written using _kernel_swi or _swi. The Acorn port of
LibTIFF can take advantage of this if present. Edit the Makefile and go to
the Static dependencies section. The first entry is:

# Static dependencies:
@.o.tif_acorn:   @.c.tif_acorn
        cc $(ccflags) -o @.o.tif_acorn @.c.tif_acorn  
Change the cc line to:

        cc $(ccflags) -DINCLUDE_OSLIB -o @.o.tif_acorn @.c.tif_acorn  

Remember, however, that OSLib is only recommended for efficiency's sake. It
is not required.