You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@harmony.apache.org by Geir Magnusson Jr <ge...@pobox.com> on 2006/06/09 01:27:41 UTC
[drlvm] building...
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.
3) It could be because I don't know the existing build system, but I
found it pretty hard to figure out all the compiler flags that were
used per 'module'. Is there an easy way? Is there a log in the current
build?
geir
---------------------------------------------------------------------
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
Re: [drlvm] building...
Posted by Garrett Rooney <ro...@electricjellyfish.net>.
On 6/9/06, Oliver Deakin <ol...@googlemail.com> 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: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [drlvm] building...
Posted by Oliver Deakin <ol...@googlemail.com>.
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
Re: [drlvm] building...
Posted by Geir Magnusson Jr <ge...@pobox.com>.
Garrett Rooney wrote:
> On 6/8/06, Geir Magnusson Jr <ge...@pobox.com> wrote:
>>
>> 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.
>
>
[SNIP]
> 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.
I'd vote to call it "common" but yes, I agree and was thinking about
this approach earlier today, but my goal is to get us minimally
integrated and working as fast as possible to let people get going w/ it
in an easy manner.
So I would think this kind of refactoring is a second step after
whatever minimal shuffling we should do to get an easy-to-grok build
systme...
>
> 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.
Thanks
geir
---------------------------------------------------------------------
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
Re: [drlvm] building...
Posted by Garrett Rooney <ro...@electricjellyfish.net>.
On 6/8/06, Geir Magnusson Jr <ge...@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.
-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