Mailing-List: contact harmony-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: harmony-dev@incubator.apache.org
Received-SPF: pass (asf.osuosl.org: domain of oliver.deakin@googlemail.com
 designates 64.233.182.186 as permitted sender)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=googlemail.com;
        h=received:message-id:date:from:user-agent:mime-version:to:subject:references:in-reply-to:content-type:content-transfer-encoding;
        b=Cowpvu8p5rtUBe2eoITYxIfm+kOquERvYi8RGpzOvZchp7OYEBlRnq5W792ugL+GL4hg3f45JJ99Q0Iw2LGNbcsqW3v0XYmNZwvhCAgfUSRvn1M5F1RN+ctMiepBAxjfIC+J+qqfk1nwjPaUihOQz3wDvmtEO0r9sWBtxHgAoKM=
Message-ID: <448951EF.8090900@googlemail.com>
Date: Fri, 09 Jun 2006 11:48:15 +0100
From: Oliver Deakin <oliver.deakin@googlemail.com>
User-Agent: Thunderbird 1.5.0.4 (Windows/20060516)
MIME-Version: 1.0
To: harmony-dev@incubator.apache.org
Subject: Re: [drlvm] building...
References: <4488B26D.6040502@pobox.com>
 <7edfeeef0606081643i71738cber87af38a94e088b6b@mail.gmail.com>
In-Reply-To: <7edfeeef0606081643i71738cber87af38a94e088b6b@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit


Garrett Rooney wrote:
> <SNIP>
>
> 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.

We actually had some discussion about doing exactly that kind of thing
a while back [1] and more recently [2]. The basic ideas were:

 - Make the code as shared as possible, by using IFDEFs where it
makes sense. We've made some progress in this area, with a lot of
our code shared, but as you say there is still more to do.
Im working on moving the native code around at the moment, so
more unification is probably something I will look at at the same
time.
 - Where IFDEFs are starting to make the code difficult to read,
split the source up into platform specific files. The kind of layout
that could be used for this is described in [2].

I think this matches what you're describing for APR. Do you
agree?

Im interested to know what kind of build system is used in APR -
previous suggestions for picking up platform specific code have
included using clever Ant scripts to figure out which file versions
are needed, or using gmake and its vpath variable to pick them
up (they are described more extensively in [1]). What does APR
use to deal with building platform specific versions of files
over shared ones?

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

IIRC Mark suggested ifdef'ing on features as opposed to platforms before
[3], and it seems like a good idea to me, providing a more obvious
reason for the existence of the ifdef and allowing us to use ifdefs that
describe more than just a ballpark platform distinction.

I think in general we have similar ideas to those you describe,
but we're not at a point yet where they have been completely embodied
in the codebase, or even summarised in a single post/page.
Perhaps I will put these ideas together into a page for the classlib
section of the Harmony website, so we have something concrete to talk
about without digging back into the mail archives.

Regards,
Oliver

[1] 
http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200603.mbox/%3c4410328E.4070904@googlemail.com%3e
[2] 
http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200605.mbox/%3c44687AAA.5080302@googlemail.com%3e
[3] 
http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200602.mbox/%3cfcb9f9160602230106v5d865575g@mail.gmail.com%3e
> -garrett
>
> ---------------------------------------------------------------------
> 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
>
>

-- 
Oliver Deakin
IBM United Kingdom Limited


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