[m-rev.] diff: disable mfilterjavac by default

[Julien Fischer]

On Wed, 16 Oct 2013, Paul Bone wrote:

> On Tue, Oct 15, 2013 at 05:48:50PM +1100, Julien Fischer wrote:
>>
>> All subsequent rotds have disabled mfilterjavac, you will need to generate
>> one with it enabled.
>>
>
> Okay, I can generate an ROTD, but then when I use it, without Mercury in my
> path...
>
>> (1) Build stage 1 using rotd-2013-04-18
>> (2) Bootcheck (or otherwise build the stage 2 compiler).
>> (3) cd stage2 && mmake install (with the java grade as one of the
>>     grades to install).
>
> I cannot run the bootcheck script, it expects mmake to be in the path but
> it's not because I don't have a Mercury installation in my path.
>
> So I commented out an "exit 1" in scripts/bootcheck and tried again.  This
> time it gets as far as building the library, at which point it reports it
> cannot find mmc, even though it used mmc in the previous step (generating
> dependency information).
>
> So I thought, maybe there's a problem with how buildcheck works and if I
> just run 'make' it will work.  So in stage2 I ran make, and there's no
> Makefile here.  I copied the one from the root of the tree and tried, it
> still can't find mmc.
>
> Are these really the steps you used to reproduce this problem?  I'm having
> trouble accepting that they worked at all before I introduced mfilterjavac.
> I'm also concerned that since it can't find mmc when I have none in my path,
> that it isn't using the stage1 mmc to build stage2 which is a problem for
> bootchecking in general.

I think the problem I had was initially just a bootstrapping problem,
i.e. rotd-2013-04-18 didn't have mfilterjavac but it was required to
install from stage2 of rotd-2013-05-01 (suitably modified to remove the
workaround that disables the use of mfilterjavac).

Ok, so now that all installations have mfilterjavac the problem should
go away?  However, why is mmake install (technically install_grades)
looking at the mfilterjavac in the PATH, not the one it has just built?
(This is potentially a problem if mfilterjavac itself changes -- however
unlikely -- in a non backwards compatible manner.)

Note that for other utility programs, e.g. mfiltercc, mkinit etc, we set
things up to look at the version in the workspace.  For example from the
top-level Mmakefile:

     SUBDIR_MMAKE =  PATH=../scripts:../util:$$PATH \
                     MMAKE_VPATH=. \
                     MMAKE_DIR=../scripts \
                     DESTDIR=$(DESTDIR) \
                    ../scripts/mmake $(MMAKEFLAGS)

     SUBSUBDIR_MMAKE = PATH=../../scripts:../../util:$$PATH \
                     MMAKE_VPATH=. \
                     MMAKE_DIR=../../scripts \
                     DESTDIR=$(DESTDIR) \
                     ../../scripts/mmake $(MMAKEFLAGS)

For me, the issue here is that you are not using the new mfilterjavac
(the java grade fails to build for me from stage 2 -- I'm not sure about
stage 1, but both should work anyway -- when the build compiler lacks
mfilterjavac, even though the workspace has just built a copy.)

In short, why do SUBDIR_MMAKE and SUBSUBDIR_MMAKE not also point at
../mfilterjavac and ../../mfilterjavac respectively.

Cheers,
Julien.