classpath
[Top][All Lists]
Advanced

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

Re: Removing the TARGET_* layer or not ?


From: Michael Koch
Subject: Re: Removing the TARGET_* layer or not ?
Date: Wed, 4 Aug 2004 18:28:55 +0200
User-agent: KMail/1.6.2

Am Mittwoch, 4. August 2004 18:15 schrieb Ingo Prötel:

> > I'm not a friend of this one-OS-one-dir approach. I would more
> > test for features with autoconf and use the features if present.
> > This makes it more easy to port to another arch. When the feature
> > is available there, use it. If not, add some code to make it
> > work.
>
> The advantage of having one-OS-one-dir is that one knows which
> files are involved. Otherwise one needs the latest autoconf run to
> determine all the variables to figure out what parts of the code
> actually runs. Or do I have it wrong?

The advantages of one-dir-fits-all was described in other mails from 
me already.

No, you are don't wrong. But the #ifdefs are normally really clear 
from the code to understand. More see below.

> > The TARGET api is really not intutive and the very long MACRO
> > names makes it even harder to understand. Sometimes the names
> > just badly choosed. The "Linux" layer is full of bugs. And I
> > suppose your other ports are too because they are copies of the
> > "Linux" layer. Some bugs are fixed in the classpath version of
> > "Linux". I wonder how many of them were ported to you other
> > ports. When an autoconf approach you wouldnt even think about
> > this. I know that with the autoconf approach the patches need a
> > closed review and more testing before they go in but IMO this is
> > much better then duplicatin bugs over several trees.
>
> I actually didn't consider long names a problem since there is word
> completion every where. If the names are badly chosen the can be
> changed. They actually follow a convention:(Quote form the
> readme.txt)
>    The naming pattern for native macros is like follows:
>
>      TARGET_NATIVE_<module name>_<macro name>
>
>    where <module name> is a name of a module, e. g. FILE; <macro
> name> is the name of the specific native macro, e. g. OPEN_READ.

Whoever invented this convention must have been drunk or so. I dont 
like like the ultra-long names because they are hard to type (that's 
no reason as you said yourself). I don't like them because they make 
the code more unreasable. When I open javanet.c in an editor I get 
blind because I only see "TARGET_NATIVE" all over the place.

> I guess the TARGET_NATIVE_ part could be shortend.

Or better removed. This prefix is really not needed.

> > I was pretty surprised when ypu wrote yesterday, that you have
> > more "ports" then just "Linux". Why don't you submitted them ? I
> > think it would be a very good idea to support as much OSes
> > upstream as possible, even Plan9 and QNX and ...
>
> I will see what I can put in. Though I don't think we have Plan9
> (At least I don't know it). But we have an RTEMS port.

That would be great.


Thanks,

Michael




reply via email to

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