Prepare & InstallTools git problem

I am getting very confused by what I think is a bug … but maybe I have misunderstood something.

In preparation for creating a test BASIC module I tried to run !Prepare, as it was some time since it was last run, and DDE30b is now installed. The !Run file sets SetPaths$Dir and then runs Prepare, which warned me that C had not been seen yet. When it ran InstallTools that gave an error with the same messsge, and stopped.

On investigation both Prepare and InstallTools check/use SetPaths32$Dir, not SetPaths$Dir. I thought my local git may not be up to date, so I Pulled it again and updated submodules, but no change.

When I checked on gitlab, the last change to Prepare seems to be on 22/05/2019, and it still checks SetPaths32$Dir. However, InstallTools was changed on 25/10/2020 to cater for both SetPath$Dir and SetPath32$Dir.

I then thought something must be wrong with my local git repository, so I cloned the All product again. Neither Prepare or InstallTools changed.

I wondered if it would be better with the Titanium product, so I cloned that. Prepare had changed – but only to remove some comments & change Print to Type. Again some things had changed, but it still used SetPaths32$Dir. How can these files be different to the All product?

So, after many hours of cloning, I have run out of ideas.
Is it a bug, or it is me?

Note that I do not really want ‘All’, but I do want to be able to build more than one product, and I can find no details of how to avoid duplicating ~160MB each time.

The !Prepare process is a bit of a muddle. Some products can auto run it on unpacking with UnTarBZ2, others don’t find it. Some products don’t need it. In any case it looks for the now obsolete SetPaths32$Dir, to get round that I have modified !SetPaths to set that in addition to SetPaths$Dir.

HTH.

Thanks David – I had thought of that, but as a git novice I was trying to do it ‘by the book’. At least it confirms it is probably not me!

The !Run file sets SetPaths$Dir and then runs Prepare

Where did that come from? The one I have (which is old, but matches PlingPrepare.!Run in git) sets ROOLMerge (Dir/Path) and then runs Prepare in a TaskWindow.

The only thing that should be setting up the SetPaths* variable is the !SetPaths application within AcornC/C++.

After a bit of rummaging, it looks like the actual path used was changed in a rather half-arsed manner in DDE30 (not thinking of the consequences of making a change to the location of the build environment, a problem that you’ve just crashed into).

DDE29 (and earlier) AcornC/C++.!SetPaths.!Run is:

Set SetPaths32$Dir <Obey$Dir>
/<SetPaths32$Dir>.SetUp
/<SetPaths32$Dir>.SetPaths

As of DDE30, it is:

Set SetPaths$Dir <Obey$Dir>
/<SetPaths$Dir>.SetUp
/<SetPaths$Dir>.SetPaths

What it should have been, because you do not make quiet changes like that, is:

Set SetPaths$Dir <Obey$Dir>
Set SetPaths32$Dir <SetPaths$Dir>
/<SetPaths$Dir>.SetUp
/<SetPaths$Dir>.SetPaths

For the next few DDE releases.

You’re supposed to go Active → Deprecated → Removed. :-)

Try patching SetPaths32$Dir into your !SetPaths run file…

PS: I began writing this immediately as I saw your message, but took a long time finding the DDE archives on my phone. Well, no, I lie. It took a long time to find my phone. :-) And then more time to find the files. And… oh, I think I’ll go put the kettle on…

The !Run file sets SetPaths$Dir

Sorry – that was misleading as it should have said the !Run file in !SetPaths.

It looks as if there were attempts to make InstallTools cater for both names for a while, but it has not worked here!

In the absence of any version numbers being stated here, what does line 27 of your clone of InstallTools in (eg.) the Titanium product say? If it isn’t

If ("<SetPaths$Dir>" = "" AND "<SetPaths32$Dir>" <> "") Then Set SetPaths$Dir <SetPaths32$Dir>

then you’ve not done the cloning step right, read the instructions again. Another check point is to download the nightly tar (usually quicker too!) and compare that with your clone. If they differ, read the instructions again.

Also check your UnTarBZ2 is version 1.11.

There is a warning from Prepare due to it looking for the old SetPaths32$Dir variable, but it appears benign.

There is no version stated in Install Tools, but that If..Set line is not present.
In the Library.VersionNum file it has “1.94 (24 Nov 2018)”

I will have yet another read of the instructions tomorrow, but apart from using All.git I believe I followed them.

There is no version stated in InstallTools […] Library.VersionNum file it has 1.94 (24 Nov 2018)

I did indeed mean the version number of the component within which the file resides (I don’t think Git supports per file versioning with the magic $Revision$ keywords like CVS does).

I cloned the All repository just now and get Library 2.06 (24 May 2021).

you’ve not done the cloning step right

Quite correct. I have now followed the instructions to the letter and tick, and have Library 2.06 (24 May 2021) which runs InstallTools without problem. The !Prepare.Prepare does still issue a warning, as you say, so that is still to be corrected.

My error was that on the initial Git Clone screen (using TortoiseGit on Win10) ‘Recursive’ was already selected, and I did not do the secondary ‘Submodule Update’. Although the help for Recursive says ‘Submodules are initialized and cloned using their default settings.’ which sounds very similar to what ‘Submodule Update’ does – and it produces a repository which looks much as one would expect – it is obviously NOT complete and correct.

Thanks Sprow for prodding me in the right direction.

The !Prepare process is a bit of a muddle. Some products can auto run it on unpacking with UnTarBZ2, others don’t find it.

It took a while but the issue here has now been found.

UnTarBZ2 1.11 uses uses a wildcard file search in !UnTarBZ2.Tools.wrap to find !Prepare.!Run

if (%0 AND 16) then repeat UnTarBZ2run %3.*.RiscOS -directories !Prepare.!Run

The wildcard is intended to match the product name, Titanium, BCM2835 or etc.

The catch is if there are other things in that directory, %3 the destination directory, such as the source code itself and its intermediate tar, the wildcard matches the first object it finds alphabetically. The source and tar have names starting src-, so if the product is Titanium or Tungsten then Prepare is not found, no such problem with Disc or BCM2835!

A minor reorganisation here will avoid this. Unpack on the RamDisc and don’t bother about keeping the source tar/bz2 and tar. By way of a bonus that halves the unpack time in the Pi’s SDFS.