Re: Mauve patches.

["C. Brian Jones" <cbj@gnu.org>]

[-- Attachment #1: Type: text/plain, Size: 2783 bytes --]

On Sun, 2004-04-11 at 15:36, Thomas Zander wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> 
> > Unless I misunderstood Thomas' question, he could not compile all of
> > Mauve because his script tried to compile _everything_, as opposed to
> > those files usually chosen by the standard build system.  I would find
> > it a little confusing if Mauve provided two build systems, one which
> > uses tags and one which does not.
> 
> You did misunderstand my question;
> the question is that I created a build system that only tests the classes I 
> select (based on ant) and I want it committed; but there seems to be no 
> maintainer that can comment on, or commit the patch.
> 
> My question therefor (to be exact) was that if some more freedom for 
> not-yet-initiated coders is allowed, I would like to have a writable 
> cvs-account which means I can continue working without waiting for more 
> then a week.

Started doing some work over the weekend to add some tests to Mauve
based on another software package I've made that has non-Mauve related
functionality.  Anyway it seems to be somewhat difficult to add
something like this to Mauve, that has extensive data sets, a small
library not in the gnu.* namespace, etc.  I've started by trying to
define the problem and generalize on potential solutions.

Problems
 
* Cannot be installed (packaged, used repeatedly for various cases from
same install)
* No integrated pass/fail/expected/unexpected summary
* Repeated executions require knowing inner workings of
various scripts
* Integration of additional libraries difficult at best
* Integration of VM specific tests also difficult
 
Solutions
         
* Change configure script to be installation oriented, similar for
Makefile.am (started this already)
* New script(s) for running mauve to compile, execute, report
results (consider using dejagnu)
	* Specify java compiler at runtime
        * Specify vm at runtime
        * Specify temporary directory at runtime
	* Specify additional libraries/resources at runtime
	* Specify additional tests at runtime

Basically all the cruft and gorp in configure.in, Makefile.am, choose,
etc. gets done over.  The TAGS system is broken, it doesn't allow one to
specify that a particular test is only valid for 1.1, 1.2, 1.3 and not
1.4+, essential to handle deprecated methods that eventually get
removed.  I have no problem doing this work, my problem is all the
people that depend on the current directory structure, build process,
etc. that will scream if something is changed.  Anyway I have started
the work, when I have a patch I'll let the list review.  Don't hold your
breath, I'm slow sometimes.  :)

Thanks,
Brian
-- 
Brian Jones <cbj@gnu.org>

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]