Re: Removing the TARGET_* layer or not ?

[Roman Kennke]

Am Di, den 03.08.2004 schrieb Ingo Prötel um 15:39:
> 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.
> 
> 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.
> 
> 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 have thought about how I would design this stuff in order to write
portable code:
1. first of all, try to stick to POSIX standard stuff ;)
2. Of course there are situations where this won't do. In this case I
would split out the non-portable stuff on a case-by-case basis in the
following scheme: Suppose you have the following expressions in a
function (pseudocode):

func() {
  exp_a;
  exp_b;
  exp_c;
}

of which exp_b is not portable. Then make a function call out of it:

func() {
  exp_a;
  do_b();
  exp_c;
}

and define the function in a file in a file in an OS-specific subdir.

the autotools should check for OSs/arches and include the correct
subdirs here. These functions must be kept minimal, in order to avoid
the effect that Michael mentioned, where you have to fix a bug multiple
times.
Note, that with this system we would avoid the use of macros altogether
(You see, I don't like them ;) I better go with a well-thought-out
design). Sure, there is the 'overhead' of 1 additional function call.
But:
1. IMO this it is still better to write readable code (hey, this is free
software and the code is supposed to be read).
2. a compiler should (when in optimization mode) try to inline such
small function calls.

As I said: I strongly vote for the removal of the TARGET_* stuff and go
with a good,readable,debuggable,etc design instead.

Best regards,
Roman