something wrong with hotspot builds in build-infra

[Kelly O'Hair]

On Oct 17, 2012, at 12:33 PM, Magnus Ihse Bursie wrote:

> On 2012-10-17 18:11, Kelly O'Hair wrote:
>> Something called fixpath.exe is failing when doing the adlc.make nmake makefile in hotspot.
>> 
>> 
> "fixpath" is the new name of "uncygdrive", since it now supports msys as well as cygwin. It will take a path such as /cygdrive/c/mydir [cygwin] or /c/mydir [msys] and convert it to c:\mydir, and then it will call the executable named as the first (non-option) argument.
> 
> So basically on cygwin configure will set CC=/cygdrive/c/mydir/build/fixpath.exe -c /cygdrive/c/msdev/bin/cl.exe
> The -c to fixpath means "use cygwin mode".
> 
> I've seen build problems before with hotspot producing compile lines where fixpath is missing the first argument to /cygdrive/c/msdev/bin/cl.exe, so it seems we're trying to compile with fixpath. This has typically been due to a problem of properly locating the cl.exe compiler. Can you check the configure output and see if cl.exe have been located and found in the proper place?
> 
> However, after the msys fixes, we now start with an argument -c or -m, but this seems to be missing as well here, which seems very strange. Do you have some mismatch between the hotspot repo and the top-level repo?
> 
> If you look at the generated spec.gmk, what does the line CC say?

I don't have those files when I use JPRT.

My primary Solaris system is svc6 which is Solaris 11 which does not work at all.
I haven't had the time to deep dive on any of this right now.

> 
>> This never was an issue before, what has changed here?
> I'm guessing either msys support or the cl.exe dection rewrite.
>> 
>> This failure will hold up any integration of the build-infra work into jdk8/build
> 
> I realize that. Overall, I feel that we have a sub-optimal workflow for pushing stuff into mainline. For pushing to mainline, we should declare a point in the source code at which we think the code is good enough to go into mainline, try it out on JPRT, make a webrev, and then only make changes that are needed to fix issues found by JPRT or the code review.
> 
> On the other hand, we still need to keep development going, and since the producure above can take days or in worst case weeks, like the latest round, we can't just freeze build-infra.

Maybe not frozen, but severely restricted is what I would recommend.

Unless the changes are needed to make this integration happen, or are needed for the integration, the repos
should be restricted.

And even after this integration, everyone needs to be doing a bit more testing of all changes being integrated
into build-infra.

> 
> I don't have a good suggestion here. Is it possible to work with branches in mercurial? Can we set a tag in mercurial and then work with a set of patches for the changes needed from that tag?

My gut feeling is that we are just moving to fast and stability and prevention of regressions to building is priority #1 right now.
Branches won't fix this and a pile of patches isn't any better than a pile of changesets.

Every change we make from now on needs to be vetted, we have too many people depending on us now.

-kto

> 
> /Magnus