something wrong with hotspot builds in build-infra

[Magnus Ihse Bursie]

This is the actual compiler we're printing. The fixpath call is just injected before the compiler call. I believe the configure log further up will say something about building fixpath and "using fixpath". 

We are using fixpath on *all* Windows builds. Otherwise we'd have to keep multiple sets of file paths (dos and unix style) or keep track of which style the path is in, and convert back and forth. This was one of Fredriks initial strokes of genius with the new build. ;-) (By incident, I discovered much later on that Mozilla builds are doing something quite similar.)

Fixpath is prefixed for all binaries that requires a dos style path. Basically, this is all Microsoft toolchain binaries, and all Java binaries. It will convert all paths on the command-line to "mixed style", i.e. c:/foo/bar.  It will convert the filenames contained in @-files, e.g. if you have like "fixpath javac @files.to.compile" we'll create a temporary file with the contents of files.to.compile converted, and run "javac @temp.file". 

It works on Cygwin by scanning for /cygdrive/X/ and replacing with X:/. On msys, we send in a bunch of directory prefixes that are needed, like /c/myrepos, /c/myutils, and scan for those and replace with c:/myrepos etc. (Just /X was not enough unique to scan for.)

/Magnus

18 okt 2012 kl. 05:57 skrev David Holmes <david.holmes at oracle.com>:

> 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