harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Hindess <mark.hind...@googlemail.com>
Subject Re: [OT] Attempting to build classlibs on a Mac
Date Thu, 11 Jan 2007 13:36:28 GMT

On 10 January 2007 at 16:34, "Alexei Zakharov" <alexei.zakharov@gmail.com> wrote:
> > 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?)
> 
> No, you just need to delete the test name from the list. As a result
> you will get an empty file but it is ok.
> 
> > 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.
> 
> This is because nobody else was trying to run tests on Mac. In your
> case you just need to create an empty file with such name if you want
> to run SegmentTest. BTW we need to add such files (probably as well as
> "excludes.Mac OS X.x86.ibm" "excludes.Mac OS X.x86.drlvm") to every
> module if we want to run tests under MacOS.

I think we should normalise the platform name to lower case (and without
spaces) as we have done with other platforms.  That is something like:

  <condition property="hy.os" value="macosx">
    <os name="Mac OS X" />
  </condition>

After the similar clause for freebsd in make/properties.xml.

> BTW, there is another way to run the test that is currently excluded:
> ant -Dbuild.module=pack200
> -Dtest.case=org.apache.harmony.pack200.tests.SegmentTest test

> > 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?
> 
> This definitely make sense. It is still a work-in-progress. Vladimir
> Ivanov was the author of the current version of exclude lists.

Agreed.  The exclude lists as they stand are going to be hard to 
maintain when we expand to new platforms.

-Mark.

> > 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.
> 
> Regards,
> 
> 2007/1/10, Alex Blewitt <alex.blewitt@gmail.com>:
> > 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 X
> ML
> > 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 caus
> e 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/ref
> erence/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.
> 
> 
> -- 
> Alexei Zakharov,
> Intel ESSD
> 



Mime
View raw message