[m-dev.] bytecode stuff in cvs repository

[Fergus Henderson]

Bert Thompson, you wrote:
> 
> |I notice that you checked in a bunch of code into a directory
> |`mercury/bytecode' in the CVS repository.  This has unfortunate
> |consequences, e.g. that code will get automatically included in
> |the source code distribution tar.gz file.  Since this code has
> |not been reviewed, that is a bug.  Can you please fix it
> |(somehow, e.g. by removing those files from the CVS respository --
> |I'm not exactly sure how to do that without causing problems, so be
> |careful.)
> 
> Andrew reviewed the code.

s/not reviewed/not publically reviewed/

I have had a brief look at the code, I have a heap of comments
for you when you think it is ready for public review.

> You're right. It shouldn't be in a source release since it's very
> much work in progress. However I want the source checked in since 
> I want to have regression tests running on it. This is inconvenient 
> if it's not checked in. 

Fine, check it in but not under the `mercury' subdirectory.

> |And can everybody else please take note that the `mercury' subdirectory
> |of the CVS repository is reserved for things that will actually be
> |included in the Mercury source distribution?  Anything checked in
> |there may be released to the world tomorrow.
> 
> If everything automatically gets bundled into the source distribution,
> then I would consider this to be a bug. I'm willing to fix up
> the release process if no-one else is inclined to.

Not "everything" gets bundled into the source distribution, only
those things under the `mercury' subdirectory.  This is a quite
deliberate design feature, not a bug.

> A simple fix is to have a list of directories that get bundled

That is an alternative design.  It would make some things easier
(e.g. excluding components from the release) but it might make some
things harder (e.g. adding a new component to the release,
and figuring out which components will be included in the release).

On balance, your suggestion may be a better design.  If you think it is
significantly better, and you want to implement it, go ahead.

> a little shell script to do the bundling should be enough.[*]

There is already a script that does the bundling.  It is the `tar'
target in the top-level Mmakefile.  In fact it gets run every night on
murlibobo as part of the nightly tests.

> [*] Standard practice is to have a formal release process one of whose 
> steps is to bundle up the stuff in the `bill of materials'.

We do have a formal release process, see
mercury/compiler/notes/RELEASE_CHECKLIST.

-- 
Fergus Henderson <fjh at cs.mu.oz.au>   |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>   |  of excellence is a lethal habit"
PGP: finger fjh at 128.250.37.3         |     -- the last words of T. S. Garp.