classpath
[Top][All Lists]
Advanced

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

Re: Removing the TARGET_* layer or not ?


From: Michael Koch
Subject: Re: Removing the TARGET_* layer or not ?
Date: Tue, 3 Aug 2004 16:01:34 +0200
User-agent: KMail/1.6.2

Am Dienstag, 3. August 2004 15:39 schrieb Ingo Prötel:
> Hi Michael,
>
> Michael Koch wrote:
> > Hi list, hi Ingo,
> >
> >
> >
> > I just started porting/testing GNU classpath to solaris (2.6).
> > Its not really different to other unices (we currently support
> > linux and *BSD) but some things are. When I wanted to do the
> > needed changes I stumbled over the TARGET_* layer which adds (in
> > my eyes) some unneeded complexity. It makes it more hard to read
> > the code and all the stuff seem to be implemented either in
> > target/generic or target/Linux with no real rule what have to go
> > where. It's just difficult to understand. In fact I try to
> > understand it since a long time and always fail because of its
> > "indirectness". Personally I think some AUTOCONF checks would be
> > more appropriate and would make the code much more readable and
> > bugfixable. There are some known bugs in it but noone attacked
> > them because none understands the code it seems.
> >
> > Ingo: Now my question are you really using the TARGET_* system or
> > is it only rotting around in GNU classpath ? I really wonder if
> > some AUTOCONF macros would be more helpful for you ?
>
> Yes, the TARGET-layer is in active use here.
>
> The TARGET-layer has two advantages:
> 1. It makes JNI-code more readable,
> 2. It makes porting simple.
>
> It makes JNI-code more readable because whenever a native function
> is called there is only one macro call. The other possibility would
> be that one has ifdefs for every system (possibly for every
> system+architecture) that one wants to support with this code. This
> would make the JNI-code difficult to read.

The MACRO names are really long and they dont really make the code 
more readable for me. Perhaps for the compiler ... I dont know.

> It makes porting easier in that one can reuse generic macros and
> only needs to override specific macros that differ for a given new
> system. And this all can happen without modifing the actual
> JNI-code. So the main step in porting is creating a new
> subdirectory in tartget name it Solaris. Copy over all the files in
> the Linux target. Add this to the include path. Then just work on
> the error that the compiler will find and where necessary create
> Solaris specific macros.

I tried to port to Solaris and you system just made it hard for me 
(and I know mjw had problems with it too when he dbugged some 
filesystem stuff).

> If there is interest we could provide our Solaris, Darwin, and
> MinGW TARGET-layer. This would probably help to understand how this
> layer is helpful. In any case we can help if anyone needs help
> understanding the code.

I don't get the benefit of the whole system. BSD's are already 
suppored by the "Linux" layer. I guess Darwin (as its a BSD too) is 
supported too and if not its easy to do so. I tried to support 
solaris in the "Linux" layer and I needed to add around 10 lines for 
it. So why add a lot oc code duplication to support an additional OS 
when its enough to add 10 lines that are much more easy to 
understand, adds no bloat and is more easy to maintain ? I haven't 
tried mingw yet but I guess its similar easy.

Sorry, but I'm currently upset because this layer made it hard for me 
to do something normally really simple. Autoconf was created to make 
it easy to write portable apps. We use it already in GNU classpath. 
Why not use it to write portable apps in it ?


Michael




reply via email to

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