Re: [Jmlspecs-developers] Problems with the JML tests in current CVS version (safemath requires regeneration of expected output)

[Clyde R. <sr...@kd...>]

Hi Gary, Patrice, et al

This explains the problem I've been wrestling with for the past three 
days.  I work on two computers and couldn't understand why, after making my 
changes, the regression tests would run on one computer and not on the 
other.  I couldn't understand why a constructor wasn't found when it was 
clearly in the source of the mjc compiler (I think the interface for that 
constructor was changed recently).  I've been running tests and diff-ing 
the directories from the two computers for two days but until now the 
significance of the extra 'multijava' directory didn't register. I thought 
it was something generated by jmldoc so didn't bother looking at it.  Also, 
I assumed that all the old .class files were deleted when we run "make 
cleanall", "make pristine", and "make rebuild-all".

I'm glad to know what was causing the problem.  I've been concerned that 
something I've been doing was causing the "paths" to go wrong (even though 
it didn't seem possible).

Does this mean that in the future when we do a "make cleanall" that this 
directory will now be deleted if it exists?

Thanks Patrice for identifying the problem and letting us know.

Clyde

At 09:42 AM 6/27/2003 -0500, Gary T. Leavens wrote:
>Hi Patrice,
>
>On Fri, 27 Jun 2003, Patrice Chalin wrote:
>
> > Once again sorry about this.  I did do a make runtests and didn't see
> > any errors.  Once Gary reported the problem I tried reproducing it but I
> > wasn't able to!  I finally tracked it down to this: outdated .class
> > files were being picked up from
> >
> > JML2/org/multijava/mjc
> >
> > This may also explain why I didn't get any errors when I did a runtests.
> >  Why are there files in this directory and how do they get there?
> >  Shouldn't a rebuild-all under JML2 clean out this directory (it doesn't
> > seem to).
>
>Ah, we thought that the JML2/org/multijava directory and
>subdirectories were only built by a bug in the multijava compiler.
>But it turns out this can happen also under the following
>circumstances:
>
>         1. You update or change something in MJ, say org/multijava/mjc/X.java
>         2. You cd to a subdirectory of JML2 and build there
>            during which compilation mjc (or whatever java compiler
>            you use) produces a .class files for the file
>            MJ/org/multijava/mjc/X.java in
>            JML2/org/multijava/mjc/X.class, because of the use of the
>            -d option to the java compiler
>
>So I agree that the Makefile in JML2 should remove all of the
>JML2/org/multijava directory when doing a make build, buildtests, or
>run-tests.   I filed a TODO item on this and assigned it to Patrice.
>Patrice, if you don't have time to do this or would rather I fix it,
>let me know, but I'm slow this week...
>
>--
>
>         Gary T. Leavens
>         Department of Computer Science, Iowa State University
>         229 Atanasoff Hall, Ames, Iowa 50011-1041 USA
>         http://www.cs.iastate.edu/~leavens  phone: +1-515-294-1580
>
>
>
>
>-------------------------------------------------------
>This SF.Net email is sponsored by: INetU
>Attention Web Developers & Consultants: Become An INetU Hosting Partner.
>Refer Dedicated Servers. We Manage Them. You Get 10% Monthly Commission!
>INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php
>_______________________________________________
>Jmlspecs-developers mailing list
>Jml...@li...
>https://lists.sourceforge.net/lists/listinfo/jmlspecs-developers