[m-dev.] Re: ROTD is broken

Zoltan Somogyi zs at cs.mu.OZ.AU
Wed Jul 18 13:49:57 AEST 2001

On 17-Jul-2001, Tyson Dowd <trd at cs.mu.OZ.AU> wrote:
> Perhaps we should simply back out the changes that caused the ROTD to
> break, since neither of them are particularly necessary at the moment.
> This would mean turning off building of the deep_profiler directory and
> turning off the testing of mlds_to_gcc.m.

I can't speak about mlds_to_gcc.m, but I did a "tar tf" on an unzipped copy of
mercury-compiler-0.10.2-beta-2001-07-17.tar.gc in
/home/venus/ftp/pub/mercury/beta-releases. What I found was not what I

First, that file is huge (over 90 Mb, even when gzipped). This is not all that
surprising, given that 40% of it (when unzipped, probably more when gzipped)
is the subdirectory bindist/mercury-rotd-2001-07-16.alphaev5-dec-osf3.2, which
has no business being there.

Second, the only files in the deep profiler subdirectory of the rotd are the
CVS subdir and a marker file, .deep.tags. Not only are there no .c files,
there are no .m files. This was caused by CVS/Entries in
/home/mercury/public/test_mercury/test_dirs/murlibobo/mercury being almost
empty. A "cvs update" in the deep profiler directory being ineffectual, I
tried to delete the directory and recreate it; that did not work either.
The reason is that the same test directory is being alternated between
the release branch and the trunk. It seems that for some reason, the release
branch deep profiler directory was being used even when the rest of the mercury
directory was on the trunk.

Third, files which have been deleted from the CVS repository (such as
compiler/vn*) are still in the rotd.

All these suggest to me that turning off the building of the deep_profiler
directory is not the right fix, and that the current process of building the
rotd is significantly broken.

- At the least, we should exclude binary distributions from the source
  distribution tar file.

- We should be using distinct test directories for distinct CVS branches.

- From time to time (say once a week), we should also delete each test
  directory and check it out from CVS from scratch, to get rid of stale files.

- We should consider moving the job of preparing the tar file from murlibobo to
  venus, or to earth or mars. Moving the job away from murlibobo will also
  allow us to avoid special casing the use of two tag bits for the source
  distribution, allowing the Alpha binary distribution to use three tag bits
  without requiring recompilation. Given that test_mercury is deathly slow on
  murlibobo, any speedup is welcome.

Tyson, if you need the rotd fixed ASAP, you will have to do the honours. If you
don't, I will discuss the issue with Fergus when he gets back from leave on

mercury-developers mailing list
Post messages to:       mercury-developers at cs.mu.oz.au
Administrative Queries: owner-mercury-developers at cs.mu.oz.au
Subscriptions:          mercury-developers-request at cs.mu.oz.au

More information about the developers mailing list