Build environment and CVS work

I thought someone would say that! ;)

Did you first initialise your local repository by doing a cvs init to create all of that CVSROOT stuff in the root of your repository mirror?

I hadn’t done that, actually. I have now, but it makes no difference. I still get exactly the same error. Do you have a working RISC OS setup there, Steve? If so, could you tell me what you get for the output of the following:

perl -le 'print @INC'

perl -le 'print @PATH'

perl -le 'print @HOME'

I don’t think my @PATH and @HOME environ. variables are getting set up correctly, as my output to the second and third of the above gives an empty string. ;( That seems to be the problem I’m facing looking at the errors (‘use of uninitialized value’ in both Perl’s internal Unix.pm and the ROOL perllib/Pace/Cvsrc file). Thanks.

I’m afraid I don’t use RISC OS cvs (or haven’t for a long time) and never tried our perl scripts on RISC OS, so my debugging won’t help you much… FYI, PATH and HOME output a dot ”.”.

Okay, Steve. Thank for getting back to me, anyway. I did have a play around installing the (even older) version of Perl from the BBE downloaded as part of one of the source tarballs on this site, but that didn’t want to play, either. The original Perl I was using was from the Acorn C/C++ CD. Anyway, maybe I’ll give up on this for now, and start working on more useful things! Maybe I’ll post some general RISC OS Perl queries on comp.sys.acorn or something…

I was thinking about how to build without having to merge the CVS checkouts together and remember that many years ago there was an image filesystem ‘LayerFS’ which allows directories to be overlayed. It turns out that the source is now available from http://layerfs.sourceforge.net.

I’ve not spent much time with this, but it looks promising. Setting up layers for each of the mixed, gpl, bsd, etc. directories and adding a writable empty directory ‘build’ shows a few issues:

• It doesn’t deal with the CVS issues.
• The Clean phase appears to lock up LayerFS somewhere.
• There are some errors expanding wildcards stopping some libraries building.

That looks really interesting – I’d never heard of it before. I’ll have a play around with it. It’s conceptually similar to the new ‘Libraries’ idea in Windows 7, but sounds quite a bit more powerful. Thanks for the link!

If anyone else is interested, I found the original webpage for LayerFS here. It doesn’t seem to be linked from the Sourceforge page. Also, I don’t actually see the source anywhere! Have I missed something glaringly obvious?

It isn’t that obvious, I should have mentioned that you can check out from the sourceforge CVS. It builds as is with Norcroft. I haven’t found much in the way of documentation and the source comments are in German which I don’t know.

Following an extended period of trial and error (with most of the error being due to Perl misbehaving), I’ve now managed to get the CVS scripts ‘working’ on RISC OS.

First off, don’t bother with trying to use the version of Perl that ROOL use. It’s horribly broken (‘use File::Path’ doesn’t work) and seemingly too out of date (or at least the Config/pm that I copied over from Alex Waugh’s version didn’t work).

Instead, you should be using Alex Waugh’s version. His version is far from perfect, but it seems to ‘work’ well enough for the checkout script to start downloading stuff (and then StrongED crashed, leaving me with an orphaned taskwindow. But it’s still downloading!)

Here’s a rough guide for what to do. Unfortunately I can’t really test the steps at the moment, since I’m letting the orphaned taskwindow run its course.

• Make sure you’ve got a working copy of CVS (e.g. John Tytgat’s version)
• Get a copy of the CVS scripts using the instructions on this page
• Make sure all the perl files have their filetype set to ‘Perl’! In practice this means all the files in the bin folder apart from cvsclear and cvsinfo (which are bash scripts). There’s no need to set the filetype of any files in subfolders.
• Ensuring Perl has been seen, execute the following to create some ‘autosplit’ files which should have been in the distribution but weren’t:

dir <perl$dir>.lib.perl5.5/8/8
perl -e 'use AutoSplit; autosplit("POSIX.pm", "auto", 0, 1, 1)'

• Create an obeyfile containing the following (but without the mailto nonsense in the CVSROOT line):

wimpslot 20m
set alias$cvs /<CVS$BinDir>.cvs -z9 %%*0
set CVSROOT :pserver:<a href="mailto:anonymous@riscosopen.org">anonymous@riscosopen.org</a>:/home/rool/cvsroot
set UnixEnv$cvs$sfix ""
set cvsscripts$dir <obey$dir>.bin
if "<cvsscripts$pathisset>"="" then set run$path <cvsscripts$dir>.,<run$path>
set cvsscripts$pathisset yes
set PERLLIB /|<cvsscripts$dir>/perllib
set USER wibble

The obeyfile should be placed in the same directory as the ‘bin’ folder, so that <cvsscripts$dir> ends up pointing at the ‘bin’ folder. Now all you need to do is make sure both CVS and Perl have been seen (it looks like you actually need to run !CVS in order for it to set up all the required system variables), open a taskwindow, and run the obeyfile (from within the taskwindow, preferably – as it will set a nice big wimpslot). Then you should be free to make use of the CVS scripts.

Known issues/other stuff:

1. During the course of today I’ve had many instances where running a program (e.g. grep) will result in memory corruption. This corruption then often (but not always!) resulted in a crash in the FindItem routine in Kernel.s.Oscli when trying to run subsequent programs. But this is probably just a sign that my Iyonix is about to die, rather than a problem with the Perl/CVS stuff.
2. At some point I’m sure that the scripts were failing to load due to the Cwd module being broken. But then after trying ROOL’s version and rebooting, Alex’s version magically started working.
3. As mentioned above, StrongED crashed shortly after I started the checkout script running. I’ve also had the checkout script crash due to running out of memory (before I increased the wimpslot), which then caused a crash in the AcornURI module when I tried running it again.
4. The ‘set USER wibble’ line is just to workaround the ‘I don’t know who you are!’ complaint that the CVS scripts produce
5. Running the above script multiple times will make your run$path longer and longer. Now fixed.
6. I’ve only tested the checkout script, don’t be surprised if everything else is broken
7. I’ve got no idea whether my custom CVS alias actually gets used. It certainly is getting used, because cvs isn’t anywhere on my run$path.

I’ve got no idea whether my custom CVS alias actually gets used. Thus it may not actually be downloading everything with compression enabled! I’m sure there’s a better way of enabling compression somewhere (or maybe the CVS scripts do it for you? I haven’t checked)

Apparently it’s possible to set a default compression level in the .cvsrc file.

Another oddity to add to the list: Now that the checkout script has completed I’m merging the folders so I can do a test build. But while moving one folder into another the interactive filer operation stopped halfway through with an error about one of the files (an ordinary text file) already being open. Using one of my BASIC utilites to dump out an open file list did reveal that the file was open. But aborting the filer op seemed to cause the file to close, allowing me to start another op to move the rest of the files.

set run$path <obey$dir>.bin.,<run$path>

can’t you use the AddPath command instead or was that introduced by RISC OS Select?

AddPath run$path <obey$dir>.bin.

But while moving one folder into another the interactive filer operation stopped halfway through with an error about one of the files (an ordinary text file) already being open.

I’ve seen this in the past and have a suspicion that Filer_Action is using the directory entry offsets returned by OS_GBPB 8..12 in a way which fails every so often.

can’t you use the AddPath command instead or was that introduced by RISC OS Select?

It looks like that’s a Select feature, since it didn’t work when I tried it this morning.

But while moving one folder into another the interactive filer operation stopped halfway through with an error about one of the files (an ordinary text file) already being open.

I’ve seen this in the past and have a suspicion that Filer_Action is using the directory entry offsets returned by OS_GBPB 8..12 in a way which fails every so often.

Yes, you’re probably right. I’m sure Ben or someone else at ROOL mentioned a while ago that those OS_GBPB calls aren’t safe to use from taskwindows because the OS uses a shared area of memory to track the state of the directory scan. Maybe something in the background (although I can’t think what) happened at the same time and managed to break it.

I’ve now managed to get the CVS scripts ‘working’ on RISC OS.

This is good news. I’ll be giving this a try as soon as I get the chance. Wasn’t so long ago you said this, Jeffrey:

...Since you’re the only one who’s mad enough to try running the scripts under RISC OS! ;)

But I knew you’d see sense in the end!

You should be using Alex Waugh’s version.

Would this then interfere with the Perl scripts used in actually building RISC OS? In other words, do you need to use Alex’s Perl version to fetch the sources, and then switch the ROOL’s antiquated version to build the sources?

I’ve now updated my post with a better script (no run$path growth, and no messing around setting PERLLIB). I’ve also confirmed that the cvs alias is getting used (cvs isn’t on my run$path, so everything must have been using the alias for it to work at all), and had a go at using the <program>$heap system variables to force things to use a dynamic area instead of a potentially troublesome wimpslot (didn’t work – I guess neither of the programs use a new enough version of UnixLib)

Would this then interfere with the Perl scripts used in actually building RISC OS? In other words, do you need to use Alex’s Perl version to fetch the sources, and then switch the ROOL’s antiquated version to build the sources?

Not sure. I think all the scripts used in the build system are quite simple (i.e. they don’t rely on any of the RISC OS specific features that are missing from Alex’s Perl port). But it’s probable that they rely on RISC OS format filenames, which Alex’s Perl might baulk at. I guess the only thing to do is for you to try it and find out :)

I guess the only thing to do is for you to try it and find out :)

Sure thing; will do. Just thought you might’ve given it a whirl yourself. Will report back once I’ve tried it.

Looks like Alex’s Perl port needs rebuilding from source to get it to run on the Beagleboard. I had a quick go. The instructions made it sound simple but I failed early on.

Thanks for all this info, I’ve (hopefully) managed to commit a new version of !ResEd using RISC OS tools only.

For future reference, here’s what I did:

Use Nettle to open the ssh tunnel to the secure CVS server. The ssh command is

ssh rool(at)beta.arachsys.com -g -L2401:riscosopen.org:2401

Use John Tytgat’s CVS port to check out the ResEd source. Select transport ‘pserver’, username and password as provided by ROOL, and host ‘127.0.0.1’.

Alternatively if you have set up the ssh tunnel on another machine (maybe a Windows machine using Putty) set the host field to the IP address of that machine.

The rest of the build environment I had got from the older source releases. I didn’t use the perl ’checkout’ script.

I actually worked on my checked out copy of the source, because, as ResEd is an application rather than an OS component, the build process is simpler and it doesn’t matter if you get CVS directories showing up in a test build. Obviously you wouldn’t build a distribution copy this way.

Then I followed Jeffrey’s instructions above on how to get the perl scripts working. In a taskwindow I did a cvs login before running srccommit. It seems to have worked, the commit has appeared in the revision history.

So, thanks everyone for the help in getting to this stage!

Bugger, I knew it was too good to be true!

The VersionNum file seems to have been updated incorrectly – the version is correct but the date is 13 March 1975!

The clock on my Iyonix was wrong, I have no idea why, but it was set to the year 2111. I do remember some sort of date related bug in RO5, can’t remember the details. Anyway, I did another commit and didn’t update the version number. I hope this was the correct thing to do.

Going to bed now :)

The details are very simple. Install RISC OS 5.16.

I bet we’ll still be receiving posts like this one when the year actually is 2111…

In fact I flashed the machine to 5.16 earlier today, it’s a ‘recycled’ motherboard from work. But the clock must have been corrupted before I flashed it, and I didn’t notice.

By the way, if you need to merge your working copy of source back into the CVS dir structure for a commit, a very good RISC OS tool (IMHO) is !DirSync

You can tell it to exclude all “CVS” directories, and then it gives you a side by side diff of all changed files. The combination of this and Harriet Bazley’s !SideDiff is so useful I use it every single day.

PS I edited my post above to give a few more details about CVS via ssh tunnel.

Note to self (and for posterity). The “-z9” switch to cvs seems to break things. Or maybe it just takes forever to perform the compression, either way a srccommit goes much more smoothly if this option is omitted.

-z9 works OK on my Linux PC (or at least I think I’m using -z9 there!). Chances are it’s just being slow because you’re using a (comparatively) slow ARM chip instead of a beefy x86 one.

I suspect you can get by with using a lower compression setting without ROOL getting too upset about their bandwidth costs.