This is the mail archive of the mailing list for the Mauve project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Mauve patches.

On Sun, 2004-04-11 at 15:36, Thomas Zander wrote:
> 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.

* 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
* Change configure script to be installation oriented, similar for (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,, 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.  :)

Brian Jones <>

Attachment: signature.asc
Description: This is a digitally signed message part

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]