RISC OS Open Support: Difference between revisions

From RISC OS
Jump to navigationJump to search
(New page: This page is in support of tools and functionality used by [http://www.riscosopen.org RISC OS Open] sources. == bzip2 == bzip2 is required to access ROOL archives. This can be accessed:...)
 
(Notes so far)
Line 3: Line 3:
== bzip2 ==
== bzip2 ==


bzip2 is required to access ROOL archives. This can be accessed:
bzip2 is required to access ROOL archives. This can found here:


* As a [http://www.riscos.info/packages/ riscos.info packages]
* As a [http://www.riscos.info/packages/ riscos.info packages]
Line 10: Line 10:
== Building ROOL Sources with GCC ==
== Building ROOL Sources with GCC ==


It is possible to build parts of RISC OS using GCC, but more work is required. The process will be documented here when it is ready.
I have been looking at the problem of compiling the RISC OS sources from [[ROOL]] using GCC. There are a number of distinct problems to be solved. This documents the issues.

== Aim ==

Allow build of all, or at least, significant parts of the RISC OS sources sufficient to build a minimal ROM, or to allow improvement of the core RISC OS apps (Paint, Draw, etc). For the ROM target, a reasonable choice is the IOMD build (RiscPC/A7000), since I can easily test this under [[RPCEmu]]. The goal here is to build using the [[GCCSDK]] cross compiler on Linux, but also at least be able to build some of the components natively under RISC OS using GCC. It is imperative that the source continues to be build using the native Acorn C/C++ suite.

=== Filenames ===

==== CVS Names ====

The C files in the ROOL CVS are in RISC OS format, which is an issue when trying cross compile. That is, c.progname (where c is a directory name), rather than the Unix format progname.c. In many cases, using CVS or Subversion under RISC OS will deal directly with Unix format names, and convert locally to RISC OS format (which is why this isn't generally an issue). But it's not really convenient to a source-wide rename. It would be possible to modify the GCC cross compiler to understand these names, but it still causes problems for 'make' and precludes use of other tools later on (e.g. lint).

The solution I have taken is instead to have a script that creates a symlink of the sources into the canonical names. This script do other things such as linking "Makefile.GCC" to just "Makefile" in the symlinked directory. It also allows separation of native build objects from the cross ones.

==== Includes ====

Many C #includes refer to "h.filename", rather than "filename.h". Again, GCC could probably be patched to understand this, but it's better to simply fix them up. In my local sources I have done this in an automated fashion, and have several hundred pending changes to CVS.

There are some wackier names, like "h.dirname.filename", which really require some manual path changes in CVS. This only occurs in a few places, but I have pending changes for these also.

Finally, because of the case-insensitivity of the RISC OS filename handling, in many instances, the #include names do not match in case. This is generally a manual fix as I go along.

Some of these same issues apply to assembler, such as reversing s.filename in GET statements.

Revision as of 15:57, 31 May 2009

This page is in support of tools and functionality used by RISC OS Open sources.

bzip2

bzip2 is required to access ROOL archives. This can found here:

Building ROOL Sources with GCC

I have been looking at the problem of compiling the RISC OS sources from ROOL using GCC. There are a number of distinct problems to be solved. This documents the issues.

Aim

Allow build of all, or at least, significant parts of the RISC OS sources sufficient to build a minimal ROM, or to allow improvement of the core RISC OS apps (Paint, Draw, etc). For the ROM target, a reasonable choice is the IOMD build (RiscPC/A7000), since I can easily test this under RPCEmu. The goal here is to build using the GCCSDK cross compiler on Linux, but also at least be able to build some of the components natively under RISC OS using GCC. It is imperative that the source continues to be build using the native Acorn C/C++ suite.

Filenames

CVS Names

The C files in the ROOL CVS are in RISC OS format, which is an issue when trying cross compile. That is, c.progname (where c is a directory name), rather than the Unix format progname.c. In many cases, using CVS or Subversion under RISC OS will deal directly with Unix format names, and convert locally to RISC OS format (which is why this isn't generally an issue). But it's not really convenient to a source-wide rename. It would be possible to modify the GCC cross compiler to understand these names, but it still causes problems for 'make' and precludes use of other tools later on (e.g. lint).

The solution I have taken is instead to have a script that creates a symlink of the sources into the canonical names. This script do other things such as linking "Makefile.GCC" to just "Makefile" in the symlinked directory. It also allows separation of native build objects from the cross ones.

Includes

Many C #includes refer to "h.filename", rather than "filename.h". Again, GCC could probably be patched to understand this, but it's better to simply fix them up. In my local sources I have done this in an automated fashion, and have several hundred pending changes to CVS.

There are some wackier names, like "h.dirname.filename", which really require some manual path changes in CVS. This only occurs in a few places, but I have pending changes for these also.

Finally, because of the case-insensitivity of the RISC OS filename handling, in many instances, the #include names do not match in case. This is generally a manual fix as I go along.

Some of these same issues apply to assembler, such as reversing s.filename in GET statements.