On Thu, 2004-03-25 at 16:54, Jeroen Frijters wrote: > > Would that suit you? > > It doesn't really matter to me. I don't mind maintaining my own copy of > the VM classes. However, I do think it raises the barrier to entry yet > again. And that is not good. We want to make the project more > accessible, not less.
To run autogen.sh you need m4 anyway. And we can make sure that once the resulting tarball is created - there's no need for m4 anymore (besides this one class you've mentioned). The important thing here is also what exactly we think of when we say "macro". This is very ambiguous and many (me including) have bad thoughts when reminded about macros/#defines etc. like in C preprocessor. (macro hell? ;-) The idea, as I see it, is not to scatter the code with macros. We have already done this. SableVM would be nightmare to maintain if we didn't have m4 macros. BUT. There's quite a big BUT here. *These* macros importantly improve readability of the source. In particular, they were designed so that they don't interfere with normal C syntax, most of their usages look just like any C code, and for the non-introduced people, the macros we have may just be nonexistant at all. If you tried to take a look at the parts of my FOSDEM presentation where I was also showing some examples of how we use macros: http://gadek.debian.net/FOSDEM/FOSDEM-Prokopski-SableVM.pdf Now - I don't think we want that advanced m4 usage in Classpath because it doesn't seem needed, but we'll try to make it as nice and userfriendly as possible. Surely it should be about just as easy to read as any other .java file. I hope to be able to show you a working implementation in not too distant future. Cheers, Grzegorz B. Prokopski _______________________________________________ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath