Community
Participate
Working Groups
Even during some test builds, I've seen the "impossible" compile errors as produced by bug 372319. Hence, we can not wait until we "replace" the complete base builder. At the same time, I want to be sure to get at least one integration build on build.eclipse.org using exact same base builder (and compiler) so we can carefully check the "comparator logs" and make sure we are now getting on build.eclipse.org builds what we got before on ibm hardware builds.
I propose we get a "good" I-build this week, have the JDT team confirm the compiler (jdt.core) is what they expect it to be, then update the base builder with that compiler. As far as I know, we can just replace (just) the JDT core bundle. Suggestions welcome.
David, we can wait for a good I build, but you should also be able to use the JDT/Core of I20120320-1400 build.
Well good point, I guess it doesn't matter if you say it doesn't. The point of "waiting for a good I build" was that I just wanted to get a good build first to make that the "comparator" didn't show some unexpected "class file change" when everything is supposed to be the same in new builds. (In my experience, changing the compiler sometimes shows changes in .class files ... just because you remove dead code better, or handle null checks differently, or something ... though, that was WTP ... maybe the platform's code is so clean and pure that those small compiler changes won't change anything in their .class files :) In any case, there are no "class file changes" in our I build from this week: http://download.eclipse.org/eclipse/downloads/dropst/I20120411-0906/buildlogs/comparatorlog.txt So, taking your comment as a suggestion ... which I did welcome :) ... this week end I will update the base builder to the version of jdt.core in I20120320-1400. And then you will finally get plenty of that "parallel compiling" testing you've been waiting for! Thanks.
I'm making this change this evening. (Of course, even if its fine, it may be a while before I actually build with it :/ ... working on the 4.2 N builds now). But, here are the details, in case it turns out to be important for others ... or in case we need to revert. We have just been use a branch, named R4_2_primary as we make the transition, which was basically 3.8 M5, plus maybe a few script changes. Before making any changes for this bug, I tagged the R4_2_primary branch we were using with R38_M5 That branch/tag contained this version of JDT core: org.eclipse.jdt.core_3.8.1.v20120125-1544.jar Then I got the 3.8 I build from I20120320-1400 which had a jdt.core of org.eclipse.jdt.core_3.8.1.v20120320-0416.jar I then tagged that set of things with R38_M5PlusBug376450 As far as I know, that's all I need to do (we'll still pull from R4_2_primary branch, for now) and as long as not too much has changed we should be good to go. Will know more "after the weekend".
