Mailing-List: contact dev-help@harmony.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@harmony.apache.org
Received-SPF: pass (herse.apache.org: domain of t.p.ellison@gmail.com
 designates 66.249.92.169 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=beta;
        h=received:message-id:date:from:user-agent:mime-version:to:subject:references:in-reply-to:x-enigmail-version:content-type:content-transfer-encoding;
        b=ixU5SIpiptHPkVu6TWXCI+zTjCpvJ1Yk2ez8BHc3qDTik+e851oQbTBXrdIm1Zkq+9lGofkxzAcWo7rbHq6IV9LAihkwRZtvf4hvEsoR/z9tqelPBV4J2vGR+5yiow8S8YbrCdo0v4p+rFAZB5h2pboNAcfznilYZuuaJqmngsM=
Message-ID: <45A4DED3.4000803@gmail.com>
Date: Wed, 10 Jan 2007 12:40:51 +0000
From: Tim Ellison <t.p.ellison@gmail.com>
User-Agent: Thunderbird 1.5.0.9 (Windows/20061207)
MIME-Version: 1.0
To: dev@harmony.apache.org
Subject: Re: [OT] Attempting to build classlibs on a Mac
References: <636fd28e0701091724k10cf61f5y2899258ebfd55632@mail.gmail.com>
In-Reply-To: <636fd28e0701091724k10cf61f5y2899258ebfd55632@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

Alex Blewitt wrote:
> 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.

You're right, we could be more specific with the dependency checking.
If you run  "ant build-java"  it still checks for the natives
dependencies, which is strictly unnecessary.

> 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.

Or, since it is just the Java code you are interested in, just grab an
HDK for any platform.  You only need the common Java code JARs to
compile against anyway if I understand you correctly.

> 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.

It is downloaded for inclusion in the JDK tools (used by Harmony's javac
exe).  There was a discussion of how to get it automatically onto Ant's
classpath, but IIRC it required unnatural acts.

> 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.

Looks like you and Nathan sorted this doc problem.

> 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'

What a pain.

We should also map that command-line argument in our tools adapter.
I'll raise a JIRA.

> 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.

CRYPTO and SECURITY modules put some test support code in there.  You
should not need it on your classpath (and those modules should likely
use build/test_support).

> 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?)

I believe so.

> 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?

It should, I forget who was looking after the exclude list stuff.
Hopefully they are reading this.

> 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.

As above, I'll let The Excluder answer.

> 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.

Cool - thanks.

Regards,
Tim