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: Guilhem Lavaux
Subject: Re: [Fwd: [cp-patches] [RFC, Concept proposal]: Easing "target" dependency]
Date: Sat, 03 Dec 2005 11:21:30 +0100
User-agent: Mozilla Thunderbird 1.0.2 (X11/20050322)

Hi Mark,

Mark Wielaard wrote:
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).


Ok. No problem with that. I would rather use classpath_ completely though to avoid namespace confusion.

Thanks,

Guilhem.

Thanks,

Mark





reply via email to

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