[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
Sincerely,
Torsten
- Target native layer, Dr. Torsten Rupp, 2004/08/10
- Re: Target native layer, Mark Wielaard, 2004/08/10
- Re: Target native layer, Roman Kennke, 2004/08/10
- Re: Target native layer, Dr. Torsten Rupp, 2004/08/11
- Re: Target native layer, Michael Koch, 2004/08/11
- Re: Target native layer,
Dr. Torsten Rupp <=
- Re: Target native layer, Michael Koch, 2004/08/12
- Re: Target native layer, Dr. Torsten Rupp, 2004/08/12
- Re: Target native layer, Michael Koch, 2004/08/12