Showing changes from revision #9 to #10:
Added | Removed | Changed
Here are some very quick questions answered regarding the RISC OS build process:
!Builder
?All of those ‘errors’ are actually nothing of the sort. This dates back to the days when scrbuild (the binary which is hiding behind !Builder) was only used for ROM builds and they considered having the same module in a build multiple times to be an error.
For other builds, such as disc builds, this is no longer the case; you often want to have multiple builds of a given component. We just haven’t got around to clobbering scrbuild yet.
This is usually because mkdir
isn’t working correctly. We have a tool called mkdir
in the RiscOS.Library.UNIX
directory which is a simple port of the UNIX mkdir
command, including the ”-p” switch which means create parent directories if they also don’t exist.
Some people already have a utility called mkdir
installed on their system that doesn’t implement the -p switch, or they have an alias for mkdir
which simply calls cdir
, both of which stops our one from being run.
Check for the alias being set or another version of mkdir being present on your machine (e.g. in !Boot.Library
).
This can often be because the version of perl installed on your machine is different (often much newer) than the one supplied in the RISC OS BBE.
Many of the perl scripts in the build process only work well with that particular version. You should unset all perl-related system variables and run RiscOS.Apps.!perl
manually to ensure that the correct version of perl is available to the build process.
If anyone out there wants to update our perl scripts to work on a current port of perl, they should get in touch with us at info@riscosopen.org.
The RISC OS build environment has a directory called RiscOS.Export
which is a shared location into which components export header files and library binaries.
You should try to ensure that this directory is fully populated before you start working on a component. Load the RiscOS.Apps.!Builder
application and run the “export headers” and “export libraries” phases on a “ “Disc” build.ROOL.BatchOne” and “ROOL.BatchTwo” build.
If you look in various Makefiles within a component’s sources, you will notice phases called export_hdrs and export_libs which perform this export operation.
Finally, it’s possible that the problem component simply is cannot not in a working state. This may be due to recent changes making it fail to build which will usually be resolved by the developer concerned, or because it the depends upon another component which isn’t we’ve actively not participating released yet. Unfortunately, it’s not possible to release components in the any order of dependencies nightly builds so this nobody’s will noticed be for a months problem or from even time years. to time.
If we’ve still not given you the answers you are looking for, drop an email to us at info@riscosopen.org.