something wrong with hotspot builds in build-infra

[David Holmes]

The log

http://prt-web.us.oracle.com//archive/2012/10/2012-10-17-145309.kohair.jdk8-build//logs/windows_i586_5.1-fastdebug.log

doesn't indicate configure is using fixpath at all.

Tools summary:
* Boot JDK:       /cygdrive/c/jprt/products/p1/jdk7u7~1/jdk17~1.0_0
* C Compiler:     Microsoft CL.EXE version 16.00.30319.01 (at 
/cygdrive/c/progra~1/micros~2.0/vc/bin/cl)
* C++ Compiler:   Microsoft CL.EXE version 16.00.30319.01 (at 
/cygdrive/c/progra~1/micros~2.0/vc/bin/cl)


I am not familiar with the windows build, but could this be the problem 
with the explicit setting of MAKE?

David

On 18/10/2012 5:33 AM, 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?
>
>> 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.
>
> 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?
>
> /Magnus