Re: [OT] Attempting to build classlibs on a Mac
On Jan 11, 2007, at 9:00 AM, Mark Hindess wrote: I'm looking at porting to freebsd/ia32, linux/s390, linux/s390x, aix/ppc32, and aix/ppc64 - keeping these exclude list up to date with platform-agnostic issues is going to get tedious pretty fast. Most excellent - my wife was just asking me the other day what I planned to do with the S390 in the garage... (and I can't wait for the CC messages from those builds...) geir
Re: [OT] Attempting to build classlibs on a Mac
On Jan 11, 2007, at 8:36 AM, Mark Hindess wrote: On 10 January 2007 at 16:34, "Alexei Zakharov" <[EMAIL PROTECTED]> 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: After the similar clause for freebsd in make/properties.xml. +1 geir
Re: [OT] Attempting to build classlibs on a Mac
On 10 January 2007 at 1:24, "Alex Blewitt" <[EMAIL PROTECTED]> 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: > > 4) The build.xml I was editing had a reference to > > > > 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. I think that location, ../../build/tests, used to be used for common test classes. I think these are now covered by the test_support.jar that is already included in the classpath (where it is needed). That line can probably be removed. You shouldn't need to point to build/classes since the classes should be present in the jars on the bootclasspath anyway. -Mark.
Re: [OT] Attempting to build classlibs on a Mac
On 10 January 2007 at 21:23, "Alex Blewitt" <[EMAIL PROTECTED]> wrote: > On 10/01/07, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote: > > > > On Jan 10, 2007, at 8:34 AM, Alexei Zakharov wrote: > > > > > Alex : > > > > >> 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. > > > > That's going to be a barrier for people. Can we be optimistic rather > > than pessimistic, and change the build to use, in the absence of the > > specific platform file, a "generic" or "base" exclude list? > > > > (We talked about this a while ago, I think...) > > Should probably be additive, too, rather than replace it. For example, > the SegmentTest was commented out in all platforms. That would have > been better solved by having a generic/base ommission of SegmentTest, > whilst still allowing a platform-specific excludes file that allows > extra tests to also be excluded. But I don't believe you should have > to re-list SegmentTest in the platform-specific excludes file just > because it was in the platform-agnostic excludes file when it was > written. +1 I'm looking at porting to freebsd/ia32, linux/s390, linux/s390x, aix/ppc32, and aix/ppc64 - keeping these exclude list up to date with platform-agnostic issues is going to get tedious pretty fast. -Mark.
Re: [OT] Attempting to build classlibs on a Mac
On 10 January 2007 at 16:34, "Alexei Zakharov" <[EMAIL PROTECTED]> 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:
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 <[EMAIL PROTECTED]>:
> > 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:
> >
> >
> > > dest="depends/libs/build/lcms/icc34.h"
> > message="${lcms.msg}" />
> > > 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.
> >
> > > 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
> > htt
Re: [OT] Attempting to build classlibs on a Mac
Hi Vladimir, I will take a look. Regards, 2007/1/11, Vladimir Ivanov <[EMAIL PROTECTED]>: Issue http://issues.apache.org/jira/browse/HARMONY-2970 was created to track problem with exclude lists. It will nice if somebody review/ comment it. thanks, Vladimir On 1/11/07, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote: > > > On Jan 10, 2007, at 4:23 PM, Alex Blewitt wrote: > > > On 10/01/07, Geir Magnusson Jr. < [EMAIL PROTECTED]> wrote: > >> > >> On Jan 10, 2007, at 8:34 AM, Alexei Zakharov wrote: > >> > >> > Alex : > >> > >> >> 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. > >> > >> That's going to be a barrier for people. Can we be optimistic rather > >> than pessimistic, and change the build to use, in the absence of the > >> specific platform file, a "generic" or "base" exclude list? > >> > >> (We talked about this a while ago, I think...) > > > > Should probably be additive, too, rather than replace it. > > Yes, that was what we had discussed before... a "common" file... > > geir > > -- Alexei Zakharov, Intel ESSD
Re: [OT] Attempting to build classlibs on a Mac
Issue http://issues.apache.org/jira/browse/HARMONY-2970 was created to track problem with exclude lists. It will nice if somebody review/ comment it. thanks, Vladimir On 1/11/07, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote: On Jan 10, 2007, at 4:23 PM, Alex Blewitt wrote: > On 10/01/07, Geir Magnusson Jr. < [EMAIL PROTECTED]> wrote: >> >> On Jan 10, 2007, at 8:34 AM, Alexei Zakharov wrote: >> >> > Alex : >> >> >> 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. >> >> That's going to be a barrier for people. Can we be optimistic rather >> than pessimistic, and change the build to use, in the absence of the >> specific platform file, a "generic" or "base" exclude list? >> >> (We talked about this a while ago, I think...) > > Should probably be additive, too, rather than replace it. Yes, that was what we had discussed before... a "common" file... geir
Re: [OT] Attempting to build classlibs on a Mac
On Jan 10, 2007, at 4:23 PM, Alex Blewitt wrote: On 10/01/07, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote: On Jan 10, 2007, at 8:34 AM, Alexei Zakharov wrote: > Alex : >> 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. That's going to be a barrier for people. Can we be optimistic rather than pessimistic, and change the build to use, in the absence of the specific platform file, a "generic" or "base" exclude list? (We talked about this a while ago, I think...) Should probably be additive, too, rather than replace it. Yes, that was what we had discussed before... a "common" file... geir
Re: Re: [OT] Attempting to build classlibs on a Mac
On 10/01/07, Alexei Zakharov <[EMAIL PROTECTED]> 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. Seems like a bit of detritus, especially if all tests are meant to run. I think the absence of a file is a stronger statement (all tests pass) than files which may have to be individually examined to determine whether there's an excluded test or not. 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 just ran the tests in the IDE and it worked :-) Alex.
Re: Re: [OT] Attempting to build classlibs on a Mac
On 10/01/07, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote: On Jan 10, 2007, at 8:34 AM, Alexei Zakharov wrote: > Alex : >> 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. That's going to be a barrier for people. Can we be optimistic rather than pessimistic, and change the build to use, in the absence of the specific platform file, a "generic" or "base" exclude list? (We talked about this a while ago, I think...) Should probably be additive, too, rather than replace it. For example, the SegmentTest was commented out in all platforms. That would have been better solved by having a generic/base ommission of SegmentTest, whilst still allowing a platform-specific excludes file that allows extra tests to also be excluded. But I don't believe you should have to re-list SegmentTest in the platform-specific excludes file just because it was in the platform-agnostic excludes file when it was written. Alex.
Re: [OT] Attempting to build classlibs on a Mac
On Jan 10, 2007, at 8:34 AM, Alexei Zakharov wrote: Alex : 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. That's going to be a barrier for people. Can we be optimistic rather than pessimistic, and change the build to use, in the absence of the specific platform file, a "generic" or "base" exclude list? (We talked about this a while ago, I think...) geir
Re: [OT] Attempting to build classlibs on a Mac
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. 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. 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 <[EMAIL PROTECTED]>: 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: 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. 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 but there wasn't a build/tests there -- there was a build/classes instead, though. In fact, without any manipulation, t
Re: [OT] Attempting to build classlibs on a Mac
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:
>
>
>dest="depends/libs/build/lcms/icc34.h"
>message="${lcms.msg}" />
>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.
>
> 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
>
>
>
> 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
Re: [OT] Attempting to build classlibs on a Mac
2007/1/10, Alex Blewitt <[EMAIL PROTECTED]>: 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: 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. These headers and libs are needed by awt. SY, Alexey
