[Top][All Lists]

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

Re: Target native layer

From: Michael Koch
Subject: Re: Target native layer
Date: Thu, 12 Aug 2004 12:42:36 +0200
User-agent: KMail/1.6.2

Am Donnerstag, 12. August 2004 12:16 schrieb Dr. Torsten Rupp:
> 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).

But a autoconf implementation would be much more understandable by 
Free Software developers. Its stuff they act with all day long. Thre 
currently TRAGET_NATIVE solution is ... well ... uncommon and hard to 
understand. What you call a "design" feature will be called "hard to 
understand" because its distributed over the whole (not really true) 
directory tree. Persoanlly I think this is a mis-feature.

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

NC (native code): We know its native code, its written in C.

TN (target native): We know its for a special target. Its in a special 
directory when using your solution.

CP (ClassPath): We know its classpath BUT this makes it easy to 
dinstiguish code defined in classpath or outside of classpath, e.g. 
system headers.

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

But we should put ALL possible OSes into ONE posix layer. Solaris 
needs no special layer. Its easy to support in a posix layer. That is 
the way Free Software developers handle it since a long time. No need 
to have it Solaris in an extra directory.

>  > I'm really glad that we now on the way to tackle the issues with
>  > the
> 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

I still have one question: what layers do you want to add and when ? I 
still saw no other layer then the mis-named "Linux" one. I ask this 
because layers for embedded OSes that we can never get in touch with 
or somehow nonsense to all outside of AICAS. We could look at the 
code but nothing else. This doesnt really help either.


reply via email to

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