harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Garrett Rooney" <roo...@electricjellyfish.net>
Subject Re: [drlvm] building...
Date Thu, 08 Jun 2006 23:43:29 GMT
On 6/8/06, Geir Magnusson Jr <geir@pobox.com> wrote:
> So I spent a bit of time playing with a basic ant/make build system like
> we have in classlib.
> 1) I think the way the code deals w/ the APR includes is broken, because
> they are of the form <apr-1/filename.h>.  This requires special handling
> of the APR disto which puts the headers in an /include directory after
> it's built on your platfom.
> I've started removing the 'apr-1' so that we have #include <filename.h>
>  Please bellow if there's some really good reason to do it as it is now
> in SVN.
> This change should be independent of the build approach we take.
> 2) Is there any benefit to mixing platform code like
>   vm/port/src/atomic/linux
>               /atomic/win
>               /disasm/linux
>               /disasm/win
> rather than
>   vm/port/src/linux/atomic
>                    /disasm/
>              win/atomic
>                 /disasm
> It's been so long since I did C in anger, I don't grok what the best
> pattern is.  I think the latter, as it *seems* easier to contruct
> makefiles, but it could be my rustiness w/ make at this point.

This is something I've noticed ever since I started looking at
Harmony's native code bits.  Splitting things into 'linux' and
'windows' isn't really an especially great way of building a portable
system.  First off, there are a lot of Unices, Linux isn't the only
game in town, not by a long shot, and you guys seem to have ended up
with cases where there is a LOT of duplicated code between the linux
and windows implementation.  When I first looked at the class
libraries, for example, the threading code was massively similar
between the two, with most of the differences being whitespace.  Now I
know there's been work in this area, consolidating code in the
classlib into common subdirectories, but some of the code I've looked
at in recent contributions still sems to have this "all the world's
either linux or windows" approach, which tells me that you might
benefit from some advice.

Now sometimes you do need to have a totally different implementation
for a new platform, but a lot of the time, there can be some minor
ifdefs (based on availability of FEATURES, not platform) that allow
the same file to work on multiple platforms.

Just splitting up into two implementations (or really N
implementations, since eventually Harmony will run on more than just
Linux and Windows) is a bit of a waste, and ifdefing based on platform
is just as bad, since the stuff that works on FreeBSD or OpenBSD or
Solaris is often the same as the stuff that works on Linux...

What we ended up with in APR is something like this:

There's a base implementation of each file that is designed to work on
any unix system.  These go in unix/ subdirectories.  If it's feasable
to make that file work elsewhere (Netware, Windows, OS/2, BeOS,
whatever) then it's done via ifdefs.  If the ifdefs get out of
control, or the platform is really that different then you start
splitting off into platform specific implementations, but that's a
last resort.

So in the end, the main things to keep in mind are to make your unix
implemenation try to work across as many systems as possible, ifdefing
based on availability of features as much as you can, not based on
specific platforms, and only as a last resort split out into totally
different platform specific implementations.


Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org

View raw message