On 6/9/06, Oliver Deakin <[EMAIL PROTECTED]> wrote:
I think this matches what you're describing for APR. Do you
agree?
That sounds very similar, yes.
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?
Well, APR has a couple of different build systems, depending on what
platform you're on. First, it's probably useful to describe the
source tree layout. It looks something like this:
apr/
file_io/
unix/
open.c
win32/
open.c
netware/
open.c
Now on unix systems, the build system is traditional autoconf + make.
The make part of things is actually generated by a python script, but
that's not really the important part, the key is that autoconf does
the "does this feature exist" and sets up a header that contains the
#defines to tell you what features are there, and then the makefiles
try and build all the .c files that live in the unix subdirectories,
if a given file is totally dependent on a certain feature, then it's
totally enclosed in #ifdefs, so compiling it is a noop.
On windows or netware or other systems, things work differently.
Windows, for example, does not have autoconf, and doesn't use
makefiles. There is a hand written header file that contains the
feature ifdefs that would normally be generated by an configure
script, and a set of visual studio .dsp files that control which files
(from both the unix and win32 directories) get built. Netware is
similar, although it uses a set of makefiles instead of .dsps.
Now, we don't particularly like the fact that the windows and netware
builds are hand maintained, and we'd like that to change. That python
script I mentioned before is the part of the unix build that goes
through the source tree and makes sure all the necessary files (on the
unix side anyway) are put into the makefile and have the appropriate
dependencies and so forth. We'd like to extend that so that with the
help of a little extra metadata (on windows you pull in this unix
file, this unix file, and then everything in the win32 directories...
you'd hope it would be as simple as 'if there is a win32 subdir use
the contents, otherwise use the unix subdir', but it turns out
sometimes you just need one or two of the files in the unix subdir) it
could also generate the .dsps for building on windows, the makefiles
for netware, etc. It would also let us generate makefiles for win32
systems (nmake). Unfortunately nobody's had the time yet.
>
> 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.
Sounds like a good idea.
-garrett
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
