[Top][All Lists]

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

Re: Target native layer

From: Dr. Torsten Rupp
Subject: Re: Target native layer
Date: Thu, 12 Aug 2004 12:16:32 +0200
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624

Dear Michael,

> 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.

It is also not redundant code now, because the special implementation also have to be used in a single-directory code-basis (currently there are separated files which are a "design"-feature; the existence of the files could be called some redundancy).

>> 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


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

I'm very happy to hear this.

>>> - shorten macro names,


> Perhaps a "CP" prefix (for ClassPath).

I would prefer some prefix which indicates the "class" of the feature instead, e. g. "NC" (native code) or "TN" (target native), not some relation to the project name (everthing in Classpath is "Classpath", thus should probably have the prefix "CP"). But if "CP" would make you and other members happy, it is ok for me, too.

> 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.

I would like to keep the files in separated directories to keep it more clear what files belong to which OS. Usually files are stored in a hierarchical order by using sub-directories. For the "hierachical" include-tree in the target-layer this was also a good idea to avoid confusion in names of files with the same function-group (e. g. "network"), but for different systems (different implementations).

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

I'm sorry for this hard discussion. But I'm happy we are one a way to keep going on together. If everybody becomes satisfied with the following new idea for a target layer, I will prepare the changes.

New target native layer:

- transform code inside macros into functions (this will make debugging possible) - the current macros become an "alias" to the functions (this is important to be able to replace a function by something special if needed) - combine posix-like systems - Linux, BSD, AIX, Solaris - into a single set of files in one directory (usage of autoconf for posix-like systems)
- add some more layers from aicas



reply via email to

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