Compiling Edit

For the purposes of experimentation I wanted to compile Edit as an application, by itself. I could never get the ROOL build machinery working, alas. In my latest efforts I note that in Tungsten.castle.RiscOS.Sources.Apps.Edit.c.message the lines #include EditIntern/txtoptmenu.h and #include EditIntern/message.h upset the compiler as it cannot find the files (nor can I!). Seeing that ROOL have compiled Edit, those files, and possibly others whose absence my compiler has not yet flagged, must be around somewhere. Have I got the wrong distribution? Can anybody help?

Apologies for the noise. Found what I was looking for using Locate in Tungsten.castle.RiscOS.Sources.Lib.RISC_OSLib.rlib and Edit has successfully compiled.

I could never get the ROOL build machinery working, alas.

Did you run into any problems in particular?

Disregarding that fact that !UnTarBz2 seems to be slightly broken (for me it keeps placing random files/folders in wrong places or fails to apply filetypes properly), after downloading the archive you’d normally need to follow the following steps:

1. Extract the archive
2. Merge together the ‘castle’, ‘mixed’, etc. folders by moving/copying the individual RiscOS folders to one location
3. If necessary use RiscOS.Apps.!EraseCVS to erase all the CVS files/folders (drag the ‘RiscOS’ folder to the EraseCVS icon on the iconbar). If you extracted using UnTarBZ2 then this should have been done for you
4. Make sure your copy of the C/C++ tools have been ‘seen’
5. Run RiscOS.Library.InstallTools to copy the required compiler binaries into the build tree
6. Reboot, to make the computer forget about your main C/C++ tools install (some of the stuff which !SetPaths does causes problems with the build system. It probably wouldn’t be too hard to find out what it is and fix it, but so far nobody’s gotten round to it!)
7. Run RiscOS.Apps.!Builder and register the build tree (the ‘RiscOS’ folder)
8. Open the main Builder window and select the right build directory & environment (e.g. ‘Tungsten’)
9. If you’re only interested in compiling standalone components like edit, then just select the ‘Export headers’ and ‘Export libraries’ option, then hit build. This will copy any shared headers into the ‘RiscOS.Export’ folder (which is where Edit was expecting to find the missing headers your build was failing on), along with compiling any static libraries that programs need.
10. If you’re going for a full ROM image, you’ll need to select ‘Export headers’, ‘Export libraries’, ‘Export resources’, ‘Make ROM’, ‘Install ROM’ and ‘Join ROM’. This will take a while (around 45 minutes on an Iyonix), but subsequent builds will be quicker, and you can obviously skip redundant steps too (e.g. you’d usually only need to do the three ROM steps)

Before doing any build of any kind (even if you’re using the numerous ’!Mk’, ’!MkSA’, etc. scripts which come with each component), you need to make sure that your main C/C++ tools haven’t been seen and that you’ve launched Builder and selected the appropriate build directory & environment. This will make sure everything is set up properly for the build (e.g. the path to the exported headers is set up, the compiler is using the right compiler flags, etc.). You might find that things work if you don’t follow these steps to the letter (e.g. if you’re compiling with your main C/C++ tools instead of allowing !Builder to set everything up), but don’t be surprised if one day you find that something is broken :)

(Most of the above information is probably on the wiki somewhere, but the fact that people keep coming to the forums with problems – and that I can never find a page which succinctly explains everything – suggests that the docs on the wiki could probably do with a few improvements making)

Thanks for this info. It was a while ago that I tried the build system; I think it was Perl that was misbehaving, despite my efforts to hide the version I already had. I will try again and let you know. Actually what I was/am trying to do is a little bit orthogonal to the build system. I want to embed Lua into Edit, so that when a file of type &18c or with a first line beginning ”#! lua” is dragged into an Edit window, the text of the dragged window, instead of being appended to that of the target window, is interpreted as a function from strings to strings which is then applied to the text of the target window. I rather fear that I may have to look at the source of RISC_OSLib rather than Edit to modify the handler for DATALOADs for txtwin objects. It is part of an exercise to make apps more scriptable.

(Most of the above information is probably on the wiki somewhere, but the fact that people keep coming to the forums with problems – and that I can never find a page which succinctly explains everything – suggests that the docs on the wiki could probably do with a few improvements making)

In the interim, I’ve linked to those 10 steps from the Build FAQ Most of it should be in How to build RISC OS but I expect some of the finer points are missing.

I also just tried to move something to a new heading on the Documents home page :

|_\2<^. Building RISC OS|
|<^{width:15em}. [[Technical notes]]|<^. Technical information on building and porting RISC OS|

If it’s lost in the ether, fortunately I still have it on the screen and so here’s a copy for a month (incorporating the above amendment). I’ve alerted info@riscosopen.org

Apparently a false alarm... although watch this space in case there are some more gremlins…

?Dunno what happened there but I’ve just pasted that code back into the page again and it’s stayed there so far…? But the previous pages aren’t there! Anyway, I’m sorry.

Here are some relevant pages from the wiki:

• The build process
• Some useful background
• An FAQ which hasn’t got many things in it

And here’s my good deed for the day: A first draft of a page describing Builder.

I’ll probably tweak it some more tomorrow (e.g. it could probably do with linking to better explanations of products files/components files/environment files). Suggestions/feedback welcome!

As a first time builder, the confusing part for me was the merging of the directories. I have figured it out now. Maybe an example would help.

Goto the RISC OS Open site : http://www.riscosopen.org/content/downloads/other-zipfiles

Download the UnTarBZ2

From “Source code archives” download the OMAP tar file (16 MB)

Create a directory ’$.Work’ and extract the tar file to this directory.

In Work you wil have the directories Autobuild, castle, mixed, OMAP3DEV, RiscOS and Utilities.

Please correct me if I am wrong:

From the castle and mixed directories, copy the RiscOS directories to the RiscOS directory in ‘Work’ so the get merged.

Open de OMAP3Dev directory. Here you find bsd, castle, gpl, mixed and Products. The first 4 directories also contains RiscOS directories. Merge them with the one in Work.

Now you are ready to use the Builder application which can be found in the merged RiscOS directory in Apps.

One of the problems at the moment is that the version of tar supplied with UnTarBZ2 doesn’t extract the archives properly, so you’ll end up with a set of folders that are a bit trickier to merge than they should be.

So taking into account the broken version of tar, the correct way of merging the folders would be as follows:

• Create a new directory, e.g. $.Work
• Extract the archive to $.Work
• If you see a ‘bsd’ folder (or a ‘castle’ folder, ‘gpl’ folder, or ‘mixed’ folder) then open it up and you should see a RiscOS folder inside. Move that RiscOS folder into $.Work.
• If you downloaded the OMAP source then you should have a $.Work.OMAP3Dev folder (or if you downloaded the Iyonix source, you’d see a TungstenDev folder, etc.). Open that folder and you’ll see more bsd/castle/gpl/mixed folders which need merging in the same way as the others (i.e. move each RiscOS folder into $.Work)
• If you see any Products folders anywhere then you can just ignore/delete those since they aren’t needed
• Clean things up a bit by deleting any folders you emptied
• What you should be left with in $.Work is a single folder, ‘RiscOS’. If there are other folders in $.Work (e.g. ‘Utilities’ or ‘Autobuild’) then those are folders which actually belong inside $.Work.RiscOS – so move them into there.

Now you should have everything merged together and you’re ready to run !Builder from $.Work.RiscOS.Apps.

Also be aware that another problem with the broken version of tar is that some files might have had random characters added to their name when they were extracted. Apart from being named wrong, this would have also prevented their filetype from being set correctly. E.g. when I extracted a copy of the Tungsten sources I had a text file called !Sprites,ff9000640. So the way to fix any files like that is to remove the whole ,xxx extension and set the filetype appropriately (the correct filetype will be given by the first three characters of the ,xxx extension).

Of course you can avoid most of the above problems by extracting the files on a PC and copying them to your RO machine over the network (assuming your fileserver software supports the ,xxx method used to encode the filetypes; I think most of them do). Just be sure to run EraseCVS to clean up the CVS folders after you’ve merged everything together (UnTarBZ2 runs EraseCVS automatically, so there’s no need to run it if you’ve used that).

Extracting the files using OmniClient over NFS works, but it takes a long time. There was one file in …Dekstop.Wimp.TestO with strange characters (arrows) in the filename which couldn’t be copied but I don’t think it matters.

OK, fixed tar. UnTarBZ2 now extracts to a single directory. It wasn’t really tar’s fault. The record in the archive is too small to hold a filename more than 100 characters.
Because I am new to this game, what do I do with the source and executable?