harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mark Hindess" <mark.hind...@googlemail.com>
Subject [drlvm] Supporting more platforms
Date Fri, 18 May 2007 07:43:09 GMT

I'm looking at what would need to be changed in drlvm to support more
platforms.  (Specifically, I'm looking at macosx/ppc32 and I'll probably
look at freebsd/x86 and maybe freebsd/x86_64.)  I thought I'd mention
some of the issues I've found so far regarding changes I plan to make
just to see if I'm taking a reasonable approach.

There are at least three locations that set up os/arch variables:

  build/make/build.xml setup.xml targets/ehwa.test.xml

For now, I'm just going to update all three, but really we need to
figure out how to reconcile these.  (Ideally, we should reconcile them
along with the classlib logic just as we need to figure out how to
reconcile the shared dependencies.)

I plan to add an if.unix property (or three ;-). Similarly, I plan to
add an osfamily variable for use in the <select /> tags.  Ultimately,
some of the directories called 'linux' might want to be renamed 'unix'
but I'll tackle that after I've seen what code is likely to be common.

Is the ant variable vm.port.includes defined anywhere?  (I spotted
${vm.port.includes} in verbose logs and just wondered if this was
intentional?)

Can we remove the env.MACHINE_ARCH variable and just use os.arch (as
classlib does)?  Or is this a workaround for people building x86_64 with
an ia32 jvm?

Quite a few files contain #include <malloc.h> but the linux/freebsd/osx
man page for malloc(3) says it should be #include <stdlib.h>.  I seem
to recall making this change in classlib code at some point, but will
fixing this in drlvm break anything?  Windows?

I'll probably start making changes over the weekend.  Once I've made the
basic build system changes then I guess I'll start looking at porting
the actual code.

Regards,
 Mark.



Mime
View raw message