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/[EMAIL PROTECTED]
[2]
http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200605.mbox/[EMAIL PROTECTED]
[3]
http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200602.mbox/[EMAIL PROTECTED]
-garrett
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Oliver Deakin
IBM United Kingdom Limited
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
