srcbuild's use of 'amu -k', and missing C++Lib

At the moment if you grab the ‘disc’ product from CVS and build it then ChangeFSI will fail to build because the C++Lib component is missing. But because ‘amu -k’ is used for the install phase, srcbuild doesn’t know that building ChangeFSI has failed, so it reports the build as having succeeded.

So two questions:

1. What’s the reasoning behind ‘amu -k’ being used for some stages (particularly for any stage which is the last in a build sequence – e.g. ‘install’). If the build silently fails then it will be tricky for autobuilders to work out whether the build succeeded or not.
2. What’s the status of C++Lib? I have a feeling I mentioned that it was missing when I first got the disc build working again, but it doesn’t look like it’s appeared in CVS yet. Or should the InstallTools script be modified to install the copy that comes with the user’s copy of Norcroft?

What’s the reasoning behind ‘amu -k’ being used for some stages?

Can’t help you there, it’s news to me.

What’s the status of C++Lib?

The advice we had from Bjarne Stroustrup (no less) on that was that we’d need Alcatel’s blessing to do a source release of C++Lib, and that it would be difficult to achieve. However, the object version is available to anyone who’s purchased the Norcroft tools which are needed to build RISC OS anyway, so we’ve filed that under “probably never going to happen”.

Or should the InstallTools script be modified to install the copy that comes with the user’s copy of Norcroft?

I think there was an InstallLibs obey file that did so at one point, though perhaps the whole script vanished when RISC_OSLib, TCPIPLibs etc got source releases? Most builds don’t use C++Libs so its absence may have gone unnoticed.