The mx gate under Windows needs some (a lot?) of work. It looks like it is flagging the line-endings for every single line in the source which makes it difficult to determine what else might be going on.
If anyone would like to help me interpret some of this Travis CI build log, and point me in some directions, then I'd be happy to piddle away at it.
Thank you.
BUILD LOG:
log[1].txt
I've moved the graal build folder to the root directory C:\graal\ and I've also edited the registry to allow for very long path names.
_Error:_
java.io.IOException: Cannot run program "C:\graal\compiler\mxbuild\windows-amd64\graaljdks\jdk11-cmp-fcce531b43f9da8f0512308b903cf1c637aa3054\bin\java.exe": CreateProcess error=206, The filename or extension is too long
^That path isn't even half of the 260 limit. So that's curious.
[ Looks like it's during: mx unittest --suite compiler --fail-fast ]
I've thought about moving the relevant JDK(s) to the C:\ root folder, as well, and then directing mx gate and mx unittest to them. I'm not exactly sure how to do that (I'm looking into it), or if the problem actually lies elsewhere...
_Build log:_
log[2].txt
https://travis-ci.com/veganaize/graal/jobs/276341234#L4011
_Maximum Path Length Limitation:_
https://docs.microsoft.com/en-us/windows/win32/fileio/naming-a-file#maximum-path-length-limitation
Looks like you're missing https://github.com/oracle/graal/commit/abbbfb377458f9c8bc8548185395cc529560a503
Yep! I'm testing the .travis.yml build against release/graal-vm/19.3
I've wanted to pull in the patched / updated releases but they are only available as 'tags'. Which means that I'd have to clone the repo to my local machine and go (a little or more) out of the way to iterate. Considering that I've been running (literally) hundreds of test builds, that doesn't appeal to me.
The second issue with releasing public updates as tags-only is that they tend to be less prominent, to users, than actual 'branches'. Considering that these updates are where security updates land I think it may be ideal to actually provide a branch for each (ie. release/graal-vm/19.3.0.2), like how it seemed to be in the past.
I will update my fork (also not appealing through GitHub) and test against the latest source (which I'd eventually need to do anyway ☺). Speaking of which, failing unit tests are not cool and I've been seeing some that should be corrected or deleted (which I'll probably wander toward after all of this).
I suggest you do this work as a PR on graal/master. That's where it will eventually end up being integrated.
Not sure I get the point about tags being more difficult than branches. What the effort difference between git merge <tag> and git merge <branch>?
Good idea, I will start the PR.
I've been primarily working through the web interface of GitHub which doesn't allow me to make edits on tags. Additionally, clicking on '_releases_' at github.com/oracle/graal doesn't (initially) show tags... So they're easy to miss for anyone who isn't used to the (somewhat quirky) GitHub flow. It just seems natural that security updates should be front & center. I'd mentioned that as a means to add some weight to my little argument against the tags ☺.
I will suck it up and clone, and work on it in the traditional manner.
Thanks for soldiering on - I sense success is not far away ;-)
Hey @veganaize, you're a little further along getting Graal to build on Travis CI on Windows.
I was just looking what your .travis.ymlnow looks like, but can't find your changes anymore.
If you have any semi-working state, I would try to pick up where you left and hopefully be able to contribute.
Or maybe we could even collaborate directly (Skype/Hangout/...) to push this forward.
@nightscape You can do a manual build by following: https://github.com/oracle/graal/issues/1887#issuecomment-558900612
Here is a link to the pull request: https://github.com/oracle/graal/pull/2085