Community
Participate
Working Groups
From http://bugs.gentoo.org/show_bug.cgi?id=92606, apparently current versions of ant want the classpath in LOCALCLASSPATH. diff -ur eclipse.orig/build eclipse.amd64/build --- eclipse.orig/build 2005-05-13 21:38:39.000000000 +0300 +++ eclipse.amd64/build 2005-05-23 21:50:52.000000000 +0300 @@ -56,9 +56,9 @@ then ORIGCLASSPATH=$CLASSPATH;export ORIGCLASSPATH ant -q -buildfile jdtcoresrc/compilejdtcorewithjavac.xml - CLASSPATH=$PWD/jdtcoresrc/ecj.jar:$CLASSPATH;export CLASSPATH + LOCALCLASSPATH=$PWD/jdtcoresrc/ecj.jar:$CLASSPATH;export LOCALCLASSPATH ant -q -buildfile jdtcoresrc/compilejdtcore.xml - CLASSPATH=$PWD/ecj.jar:$ORIGCLASSPATH;export CLASSPATH + LOCALCLASSPATH=$PWD/ecj.jar:$ORIGCLASSPATH;export LOCALCLASSPATH ant -q -buildfile build.xml $target -DinstallOs=$os -DinstallWs=$ws -DinstallArch=$arch $compilelibs $bootclasspath else echo "The os-ws-arch combination of $os-$ws-$arch is not valid."
This patch does not work, the ecj.jar is no longer on the classpath and the compile fails. Billy, can you get the person who originally commented on this issue on the gentoo bugzilla to comment on the context of this change? What verson of ant are they using?
The latest stable Ant in Gentoo is 1.6.2.
This is our ant script: http://www.gentoo.org/cgi-bin/viewcvs.cgi/dev-java/ant-core/files/1.6.2-ant?view=markup As you can see, we entirely reconstruct a valid CLASSPATH so that we know ant will run. Users invariably mess up their CLASSPATH to the point none of the system utilities work. If the user requires additions to ant's classpath, she must set the LOCALCLASSPATH env var. Debian does similar stuff, and also honour LOCALCLASSPATH in their ant, but I cannot speak for the other distros.
The reference platform for Eclipse 3.1 for Linux GTK is RH enterprise WS 3. Changing to script to use the LOCALCLASSPATH causes compilation to fail on this platform. Do you have any suggestions on how our scripts could accomodate your change and not cause issues on other distros? For instance, parsing /etc/issue.net and using the results to set the appropriate classpath variable?
please see previous comments
The dirty hack: Set both LOCALCLASSPATH and CLASSPATH. A less dirty hack: --------- sketch ----------- if [ -f /etc/debian_version] || [ -f /etc/gentoo-release ] ; then export LOCALCLASSPATH=... elif [ -f /etc/redhat-release ] ; then export CLASSPATH=... else echo "!!! Warning: Distro variant not recognized, assuming RHEL3 compatible." export CLASSPATH=... fi ant ... --------- sketch end ----------- The least dirty (but most cooky) hack: Bake muffins, bring to Billy's boss and persaude said person to let Billy hack on an automake-based build system for Eclipse with us (Gentoo), RedHat and Debian:)
I tried the setting both the CLASSPATH and LOCALCLASSPATH earlier today on RHEL. It failed with jdtcore compiler failed with an "interesting exception". Will talk to the jdtcore guys about what this means. I'll implement your if statement and see how that goes, it should be fine. It is definitely too hot to bake muffins. Beer and ice cream as bribes are definitely more in season. We want to keep the eclipse source build as close as possible to the real build process so the actual result mirrors that from the releng builds. But I understand your frustration with having to hack our scripts to create rpms etc.
fixed in HEAD
I'm the source of the patch that initiated this bug. Below is the link to the official ant shell script (as seen from the tags it is the same for th efollowing ant versions ANT_163, ANT_164, ANT_165). http://cvs.apache.org/viewcvs.cgi/ant/src/script/ant?rev=1.38.2.9&only_with_tag=ANT_165&view=markup When searching the word CLASSPATH from the script it is obvious that only LOCALCLASSPATH is passed to the java when launching ant. The only place where the plain CLASSPATH is ever touched is inside some strange rpm_mode section, which can only be enabled if defined in ant.conf. My conclusion would be that some rpm using distributions managed to get their evil CLASSPATH hack into ant build scripts and now it's biting them back. For and 1.6.3 and newer one can use the --noconfig option to make rpm_mode ant behave like any other ant.
I'm not sure how your comments indicate the need for changes to our build script. Could you provide more detail?
I do not think that futher changes to the build system are necessary. The fixes proposed in comment #6 are good as they fix the problem without hurting backwards compatibility. I was just trying to explain why I think the LOCALCLASSPATH should be supported by the build system (sorry for the delay, I was asked to do that 3 weeks ago). I also tried explained why just using LOCALCLASSPATH doesn't work with some ant installations (as suggested in my original patch in comment #1). Anyway, now that I started writing this comment I will still propose one more less hackish way to fix the LOCALCLASSPATH vs CLASSPATH problem: 1) document that ant 1.6.3 or newer is required for building eclipse 2) define only LOCALCLASSPATH 3) invoke ant with --noconfig option
Karl, your suggested change broke the source build on my debian machine at home. I had to hack the build script to stop setting LOCALCLASSPATH before the thing would build. Is there a safer way to fix this?
From reading the Debian ant file, Debian decided to invert the meaning of CLASSPATH and LOCALCLASSPATH for ant. On Debian, they collect autodetect the necessary packages for ant into LOCALCLASSPATH, then append the CLASSPATH env var. If the env var CLASSPATH_OVERRIDE is set, the CLASSPATH will be prepended. If every distro had just used the upstream ant script, things would have worked the same, but Debian apparently decided to write their own, which does not preserve the original semantics. The very best way for fixing this is having it solved upstream at apache, then enforcing every distro not to break the apache way.
But waitasec! The case I described above with the inversion of CLASSPATH vs LOCALCLASSPATH will only happen if $rpm_mode is set. Do you have /etc/ant.conf, or ~/.ant/ant.conf or ~/.antrc? On my kubuntu system, I don't, so this should never happen. (Note to self: Never reply to bugs before getting out of bed in the morning.)
As I said in comment #9 the build should use the ant option --noconfig which always disables the rpm_mode (which can only be enabled in configuration files). The only downside of this one is that at least ant 1.6.3 is required for building eclipse, but that shouldn't be a problem to anyone.
Reopening to address comment #12.
*** Bug 112192 has been marked as a duplicate of this bug. ***
*** Bug 111607 has been marked as a duplicate of this bug. ***
reverted LOCALCLASSPATH defintion in HEAD to address comment #12
Any way someone can post the new build as an attachment to this bug? I'm downloading the 3.1.1 sourcebuild (not from CVS) and can't compile it on my Debian. Wouldn't it also be wise to repackage the 3.1.1 sourcebuild that is downloadable from eclipse.org to include this patch? Zorzella
Debian is not one of our reference platforms, so no, we will not be repackaging this into a new zip. http://www.eclipse.org/eclipse/development/eclipse_project_plan_3_1.html#TargetOperatingEnvironments If you replace the file named "build" with org.eclipse.releng.eclipsebuilder/sdk/srcBuild/build in either the HEAD or R3_1_maintenance streams, you shouldn't see this error. If there is a 3.1.2 release, this fix will be included. Also, this fix is included in all current 3.2 stream builds.
It would be simpler not to have to download the entire CVS build for just one file. Isn't there, at least, a URL where you can leave the rectified "build"? Thanks, Z
I'm not saying that you should run the entire build from CVS again (src fetch) What I am saying is that you should check out only the project org.eclipse.releng.eclipsebuilder from R3_1_maintenance or the HEAD stream. Copy this named build from org.eclipse.releng.eclipsebuilder/sdk/srcBuild/build to the file named build in the root of your src build installation. We do not provide rectified builds on a download site, only patches.
Created attachment 29009 [details] patch for build file to resolve debian issues
