classpath
[Top][All Lists]
Advanced

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

Re: [Fwd: [cp-patches] [RFC, Concept proposal]: Easing "target" dependen


From: Mark Wielaard
Subject: Re: [Fwd: [cp-patches] [RFC, Concept proposal]: Easing "target" dependency]
Date: Fri, 02 Dec 2005 13:15:06 +0100

Hi Guilhem,

> On Wed, 2005-11-30 at 20:31 +0100, Guilhem Lavaux wrote:
> > So I am proposing to keep the 
> > basic skeleton of the target layer but put the real code not in macro 
> > but in real C functions. That way we will be able to add autoconf macros 
> > without bothering the java interface and if some persons still want to 
> > use the TARGET layer it is possible by simply using the macro inside the 
> > C functions.

Everything that replaces the macros with real functions has my vote. I
have had to debug my way through the macros and it was a pain.

> > So here is a patch which shows what I want to do. An idealistic 
> > situation would be to put all these functions which are using syscalls 
> > into a libjavasyscalls which will be implemented by VM writers (and of 
> > course we will propose a default implementation).

My preference would be for one cp_io.c, cp_net.c file per core package.

> > This is not the definite patch. So don't complain about missing 
> > ChangeLog and so on ... I ask whether people agree on using that concept.

This makes the source much more readable for me so I am happy. The only
thing I would like to see changed is to explicitly start all functions
with cp_ ,to make clear that these symbols are part of the GNU Classpath
library (we have the same naming scheme with the gtk+ awt peer native
implementation).

Thanks,

Mark

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


reply via email to

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