classpath
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: Classpath build process and VM-specific issues


From: Grzegorz B. Prokopski
Subject: RE: Classpath build process and VM-specific issues
Date: Thu, 25 Mar 2004 15:49:42 -0500

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






reply via email to

[Prev in Thread] Current Thread [Next in Thread]