Files
libtiff_2007/contrib/acorn
jens f81ae811ca Initial import
git-svn-id: http://moon:8086/svn/software/trunk/libsrc/libtiff_2007@1 b431acfa-c32f-4a4a-93f1-934dc6c82436
2014-07-19 07:44:42 +00:00
..
2014-07-19 07:44:42 +00:00
2014-07-19 07:44:42 +00:00
2014-07-19 07:44:42 +00:00
2014-07-19 07:44:42 +00:00
2014-07-19 07:44:42 +00:00
2014-07-19 07:44:42 +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.