Gregory Shimansky wrote:
On Sunday 12 November 2006 00:39 Geir Magnusson Jr. wrote:
Ok I think I've come up with a reasonable compromise. I still used the
whole system of converting XML and all the stuff. It does quite a lot of
things in setup and init targets and using <select> is convenient. I
don't know how to untangle all of the setup and not do a lot of
duplication in ant scripting which I am not big expert in.
Why? Why do we want to persist with this system, when WE ARE GOING TO
GET RID OF IT at some point?
One reason would be is that I don't know ant well enough to redesign the whole
stuff all together. I used the existing setup and init targets which take
care of including ancontrip and cctask jars.
If you ask me, I'd prefer make in the first place, ant is just too foreign to
me. There is no reason to use caps, we didn't even start to discuss how we
want to see drlvm build and "when WE ARE GOING TO GET RID OF IT at some
point".
The caps were to get your attention. I thought you had a nice way to
create a standalone testbed and then hook that in.
Did you also fix the silliness of having to use annotations to exclude
tests? Please? :)
No, the patch has an exclude example using and <exclude> statement in
patternset in its beginning.
Yay!
I'm glad we have these tests, but really... I wish you hadn't invested
the time integrating it into the DRLVM build system...
Even if we write a new one from scratch I want the tests right now. There were
several times when JVMTI was broken since there were no tests for it at all
since it is a special VM mode no one usually uses.
That's not the issue - we all agree we need the tests right now. What
I'm arguing about is doing the tests, and then doing the integration
into a build system we don't want.
The time invested, well... I learned a lot since the last time I used ant.
Maybe one day I'll be able to write something as impressive and
unmaintainable as the current drlvm built :)
Seriously, if we're going to change it, let's discuss it how we want it to
look like and which tool we'll use. I vote for make (gnu version, that is
gmake), even on win32 it exists in cygwin and mingw.
I think that we should simply use the same tooling that we're using now
in classlib.
geir
