[native-image] Please consider supporting non cl.exe ways on windows to compile via native-image

[rubyFeedback]

Hey GraalVM team,

I recently tried graalvm-22.0.0.2 for 64bit linux. It worked fine. I
was able to use native-image even on swing applications - not sure
if it works in general, but it seems to work fine for me on linux just
fine. My next idea was to test this on windows. Anyway.

On windows this is all a bit more complicated than on linux. :(

I tried to do the same steps, aka those that worked for me on linux,
but native-image complained that cl.exe was not found in PATH. So
it could not compile anything. Alright.

I then installed like +2.30 GB for Microsoft Visual Studio community
edition following some advice from SO. But even after trying for some time,
I still can not find cl.exe anywhere. Or I don't know where it was installed.
Went through some more stackoverflow comments but it did not help, then
I gave up.

Would it be possible to avoid using cl.exe? I have msys2 and I
can compile simple hello-world C programs on the commandline just
fine. GraalVM has some connection to LLVM so perhaps clang may also
work? But I honestly am too much of a noob to know how easy it is
to support that. I just want to avoid cl.exe if possible on windows. The
less I depend on Microsoft upstream the better for me - linux kind of
messed up my brain too, making me too impatient and lacking
tenacity. :P

Would it be possible to add more compiler-support here? native-image
could also just delegate to either clang or msys2 and download
stuff it needs in order for this to work - I am fine with all that if it ends
up with a system that works (via "native-image" that is). I am sure other
people managed to install cl.exe just fine, and use it fine as well, but I
struggle, and I don't really want or need visual studio anyway - commandline
is just fine. On Linux I just use gcc anyway most of the time (and sometimes
clang, but I am more of a gcc person still).

I don't know how feasible the above would be, but I would be fine
if msys2 or clang is limited compared to cl.exe. My use case is
primarily and mostly small java apps, ideally some swing-components too
(just the simple things - buttons, text-view ... these basic things;
the only other alternative would be to go full all-in via the
www interface, but having a standalone, drop-in .exe file would
be super-convenient to distribute towards elderly people in
particular.). Actually I'd want to avoid openjdk as well and just
all-in on graalvm now. :P

For the actual design, perhaps native-image could then have
compiler commandline options such as --compiler=msys2 or
--compiler=clang or something like that. That way it may default to
cl.exe still, but people could choose other compilers. And be notified
of that too, in that case, with mentioning what particular
commandline flag is to be used. Right now I only get the
notification that cl.exe could not be found, so appending an
additional sentence may be helpful IF other compilers are
supported too.

TL; DR: So the basic idea is to have more compiler options supported
without depending on cl.exe only..

[kkriske]

Just to get you going with the "can't find cl.exe" issue, the windows prerequisites can be found right here in the documentation: https://www.graalvm.org/22.0/docs/getting-started/windows/#prerequisites-for-using-native-image-on-windows

The step that you're missing seems to be just running in the x64 Native Tools Command Prompt.

You also don't need to install the entirety of visual studio, the Build Tools alone is enough.

[fniephaus]

Thanks for raising this issue, @rubyFeedback. As @kkriske correctly pointed out, there is only one supported way of building native images on Windows at the moment: through the x64 Native Tools Command Prompt. And for that, you only need to install the build tools.

Building software on Windows is not always straightforward and I think it's actually a good thing that we don't provide too many options that users can get confused with when building native images.

BTW: you can also build native images on Windows using our GitHub Action, which sets up an appropriate environment for you.

Please feel free to re-open this if you have any further comments or questions!

[thcase]

I feel this is "punting" on the issue. Please explain why one needs to run in the x64 Native Tools Command Prompt only. This is unworkable when in IDE's, such as IntelliJ. Developers need to follow normal workflows. The error message that "cl.exe" is missing from the path simply means one needs to add the proper "cl.exe" to the path. One can compile all other code w/o having this mapping, including Windows code requiring the build tools (VS Code does this all the time). If you won't fix it, then explain the reason this isn't working for the community to develop a solution that doesn't require opening a special terminal window outside of the normal workflow within an IDE.

[thcase]

Just a follow-up: This stack overflow (https://stackoverflow.com/questions/64197329/cl-exe-missing-when-building-native-app-using-graalvm) provides the solution. This could be easily wrote up as a manual install step for developers. They just need to find the path to the bat file and edit the native-image.cmd. For me, using the 2019 Build tools, the addition was:

call "C:\Program Files (x86)\Microsoft Visual Studio\2019\BuildTools\VC\Auxiliary\Build\vcvarsx86_amd64.bat"

[fniephaus]

Hi @thcase, thanks for your feedback. We're removing the requirement to run in the x64 Native Tools Command Prompt (see #5881) and set up build environments automatically for Windows users of GraalVM Native Image. This update is going to ship with the next GraalVM release. If you want to give it a try earlier, the update should also be available in a GraalVM dev build in a few days.

[jcrben]

UPDATE: looks like this is already reported by #6806 - since this won't be worked on I'll be using golang instead for my project

With rust / rustup you can use the msys2 toolchain to compile with gcc on Windows. I suspect graal could do the same. That would let us bypass the massive Visual Studio dependency