Re: Target native layer

[Michael Koch]

Am Mittwoch, 11. August 2004 12:37 schrieb Dr. Torsten Rupp:
> Dear Roman,
>
> > 1. We get rid of the TARGET_* layer (because we don't use it),
> > and the folks at AICAS could keep it on their own (much like some
> > specialities in kaffe, gcj and sablevm are handled). Of course,
> > this would make synchronizing their sources with the sources of
> > GNU CP more difficult.
>
> I assume if TARGET_* is removed, aicas have to do their own
> development of the native code. This would be possible, but of
> course this would not be very useful. For aicas it would be
> difficult, because we are almost "kicked-out" of the project (at
> least for the native code).

I don't wanna kick somebody out of the project. I just want to improve 
our Free Software project. I hope you dont got me wrong from the 
start.

> > 2. AICAS could contribute all their TARGET_* layer using code to
> > GNU CP. This way this layer would kinde make sense to GNU CP
> > hackers. Maybe we all can help to get rid of it nevertheless, but
> > keep CP portable on those rare systems.
>
> You are right, we are late with contributing more layers. Because
> of limited manpower we still did not contributed some more layers,
> e.g . Solaris. We like to do this.
>
> > 3. I dunno about the details, but we could go with a hybrid
> > system: Most of the portable stuff goes into the generic layer
> > and is autoconfiscated, like it was discussed to great lengths
> > now.
>
> The generic target is already doing this (at least partially). It
> is designed to use autoconf results to select the right OS-function
> or the right constants. Thus most of the code is located there. And
> that is also the reason why Linux seems to be "empty". It is not
> empty, it includes the generic cases of the target layer, thus
> there is not special implementation in Linux (please have a look at
> the final "include"-statement at the end of the files). If needed
> we can rename "generic" into "Linux" and discard the current
> "Linux". I do not want to do this, because this would look like the
> layer is limited to "Linux-like" systems.

Wouldnt it be better to call it "posix" (note: no captial letter) as 
it currently supports Linux, *BSD, AIX ... We can and should add 
Solaris too. With autoconf its really simple. Then AICAS can remove 
their own Solaris port totally and we have a clean non-redundant 
codebase for posix-like OSes.

> > In really
> > extreme cases the TARGET_* layer could be used.
>
> The extrem cases are the problem. I spend a lot of time to handle
> such cases and it is difficult to do this with autoconf only. If
> you only use Unix-like systems, probably you will not run into this
> problem, thus autoconf only is nice. But imho soon you like to use
> other systems, too, e. g. Windows or embedded systems it becomes a
> challange. I can imagine it is difficult for someone to understand
> my viewpoint, if that person is not developing software for
> embedded systems.
>
> > - get rid of (multiline) macros where feasible,
>
> Of course it would be possible to remove the "linefeeds", but that
> would not help (imho it would make it even more difficult to read).
>
> I have the following suggestion:
>
> Because the multiline-macros are to difficult to handle, we can
> replace that macros e. g. by direct function-calls. Thus a macro
> would become some "alias" only. We also can change (shorten) the
> names. For this we have to change the generic implementation. The
> advantages would be:
>
> - debugging is possible
> - type-safety
> - easier to read
>
> and for aicas
>
> - we can keep most of the code we already have written
> - we can continue to participate in Classpath
>
> For aicas this would be some compromise, because we can still use
> the target-layer. What would be still important is, that in the
> native _no_ OS-specific feature is used directly, like constants or
> datatypes or OS-functions calls. With such a implementation we can
> survive.

I like this idea. In fact I had the same in mind. 

> What do you think?
>
> > - shorten macro names,
>
> Please make some suggestion. If TARGET_NATIVE is to long, what
> about
>
> TARGET or
> NATIVE or
> NC or
> ...?

Perhaps a "CP" prefix (for ClassPath).

> Please take care that there is some risk for naming-collisions if
> the name becomes to short (thus "OS" would probably be a bad
> choice).
>
> > - group files together more intelligently and
>
> I do not understand what is wrong with the current grouping. The
> grouping is done by function-types, e. g. file, network, memory and
> so on. How to make it better/more clear?

There are several ways to deal with the files. Either do it the AICAS 
way and group one OS in one dir or do it the libgcj way and put all 
into one dir, havean OS suffix/prefix in the filename and choose the 
files are configure time.

> > - reduce (better: completely avoid) redundant code (bugs
> > multiplication!!).
>
> Ok. There are some parts of the layer which could be improved. If
> we decide to keep the target layer in the code, then we should do
> these improvements.

Yeah, we should really improve this. This needs much discussions and 
some time but will (hopefully) improve classpath' code.

I'm really glad that we now on the way to tackle the issues with the 
TARGE_NATIVE layer.


Michael