harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alex Blewitt" <alex.blew...@gmail.com>
Subject [OT] Attempting to build classlibs on a Mac
Date Wed, 10 Jan 2007 01:24:05 GMT
So, I had to check that the build.xml worked properly (as opposed to
just running in Eclipse) and had a few joys whilst doing that. Here's
what I found:

1) The ant at the top level seems to do a lot of stuff at the C level;
the dependency set-up required icc34.h and lcms.h, which I guess is
coming from the trunk/make/depends.xml:

        <mkdir dir="depends/libs/build/lcms" />
        <check-one-link src="${lcms.home}/include/icc34.h"
                        dest="depends/libs/build/lcms/icc34.h"
                        message="${lcms.msg}" />
        <check-one-link src="${lcms.home}/include/lcms.h"
                        dest="depends/libs/build/lcms/lcms.h"
                        message="${lcms.msg}" />
I'm not sure why that should be necessary if I'm just building the
Java components. In the end, I didn't follow this through, because by
then, it had whatever properties files that were needed to make it
happen.

2) Owing to running the command for just the pack200 module (i.e.
without anything else), not to mention the fact that the Mac doesn't
have a suitable VM for testing, I bodged the boot libraries by doing:

ln -s /System/Library/Frameworks/JavaVM.frameworl/Classes/*.jar
trunk/deploy/jdk/jre/lib/boot/

That seemed to be an easier way to resolve the bootclasspath errors I
was seeing in the build. I could get away with this because the
org.apache.harmony.pack200 code isn't present in the Apple JVM libs;
there's likely to be a problem doing this with the Harmony
implementations of java.* classes. Mind you, a full build of the
modules might well work anyway.

3) I ended up running ant with -Dhy.javac.compiler=modern and
-Dbuild.compilerarg=-nowarn as options, to use the built-in javac
instead of the Eclipse JDT. How come this isn't on the classpath
automatically? It's downloaded as a dependency with the fetch-depends.
I was also surprised that I couldn't set the property as described in
the top-level trunk/README.txt:

"Modifying the Java Build Compiler
---------------------------------
By default, the Java compiler is set to use the ECJ compiler. This value is
set in the HARMONY_TRUNK/make/properties.xml and looks like the following XML
element.

<property name="build.compiler"
value="org.eclipse.jdt.core.JDTCompilerAdapter" />

The compiler can be set to "modern", as per the Ant manual, which will cause Ant
to use the JDK's 'javac' tool."

I did change the property in the there (as well as on the command
line) but it had no effect. Has that property been renamed to
hy.javac.compiler and the documentation is out of date?

NB it looks like this is a cut'n'paste job from
http://help.eclipse.org/help32/index.jsp?topic=/org.eclipse.jdt.doc.isv/reference/api/org/eclipse/jdt/core/package-summary.html
which presumably has a javac target using 'build.compiler'. I suspect
this should be changed to hy.javac.compiler in the README (can supply
a patch if anyone's interested). I did run this with the new value in
the properties (along with the right compilerargs) and verified that
they ran successfully for me without the JDTAdapter.

3a) The -Dbuild.compilerarg=-nowarn is needed when not running against
the JDT compiler. The javac uses '-nowarn' whereas the JDTAdapter
seems to want -warn:none. I'd suggest pairing the lines (also: why not
hy.build.compilerarg? hy. seems to be prevalent elsewhere) with a bit
of doc like 'Uncomment to use the Eclipse JDT' and 'Uncomment to use
the command-line javac'

4) The build.xml I was editing had a reference to

            <classpath location="../../build/tests" />

but there wasn't a build/tests there -- there was a build/classes
instead, though. In fact, without any manipulation, the test classes
weren't able to see the runtime classes (this may have been the way I
had things set up though) but a symlink from build/tests to
build/classes solved the problem for me. This also seemed to solve the
problem for other build parts too, so I don't know where I went wrong
with mine.

5) The SegmentTest was failing, and so was commented out with an
excludes.linux.ibm property in the modules/pack200/make. (As an aside,
I don't know how to enable it again, since it now works; is it just
deleting this file?) In any case, when compiling this on a Mac, it was
falling over in the Ant build looking for an "excludes.Mac OS
X.ppc.ibm" file. I had to copy one of the existing ones over just to
move past that hurdle. I don't know how the build deals with excluded
files, but would it not be possible to let it work in the absence of
such files? Also, given that all of them had the entry 'SegmentTest',
would it not make more sense to have a meta-one such as
'excludes.all.ibm' in the absence of a platform-specific one? Anyway,
I don't know why the lack of this file should break a build; perhaps
if it sees one excludes.* file, it expects to find one with a
platform-specific name (which looks to be Mac OS X). I don't know what
it would be on an intel; possibly excludes.Mac OS X.x86.ibm.

Anyway, it was only a start at getting the classlib modules built in
order to test the new build.xml file; I thought I'd share my
experiences here in case anyone else does the same in the future.

Alex.

Mime
View raw message