Restore building/running TornadoVM from IntelliJ & update of documentation

[stratika]

Description

This PR (is an update of #445) and provides the following:

1. a fix in the tornadovm-installer script to install cmake and maven in the path that is compliant with the IDE xml configurations.
2. a fix in the post-installation script for building TornadoVM from IntelliJ in Windows OS. This is to trigger the pyInstaller for building the tornado executables.
3. update the documentation for the TornadoVM read-the-docs.

The idea is that now TornadoVM users can:

1. build TornadoVM (with one or more backends) from IntelliJ in all OSs (Linux, macOS, Windows).
   A user can use the Python application (TornadoVM-Build) that is in the repository, and update the Python interpreter and all configurations as described in the instructions (ide-integration.rst).

2. run/debug TornadoVM tests from IntelliJ
   A user can use the Python application (TornadoVM-Build) to run the tornado-test script. The default run invokes with the "--quickPass" argument, but it is configurable from IDE.

4. run/debug Java applications that use TornadoVM from IntelliJ

Problem description

The instructions of building/running with IntelliJ in the TornadoVM documentation page are old and not applicable.

Backend/s tested

Mark the backends affected by this PR.

• OpenCL
• PTX
• SPIRV

No backends are affected. This PR does not touch the compiler.

OS tested

Mark the OS where this PR is tested.

• Linux
• OSx
• Windows

Did you check on FPGAs?

If it is applicable, check your changes on FPGAs.

• Yes
• No

How to test the new patch?

Instructions are provided in the instructions (ide-integration.rst)

---

[jjfumero]

When I build, I see the following diff in the repo.

diff --git a/.build/TornadoVM-Tests.run.xml b/.build/TornadoVM-Tests.run.xml
index a755f7263..8f5317e98 100644
--- a/.build/TornadoVM-Tests.run.xml
+++ b/.build/TornadoVM-Tests.run.xml
@@ -5,14 +5,14 @@
     <option name="INTERPRETER_OPTIONS" value="" />
     <option name="PARENT_ENVS" value="true" />
     <envs>
-      <env name="BACKEND" value="opencl" />
       <env name="PYTHONUNBUFFERED" value="1" />
+      <env name="BACKEND" value="opencl" />
       <env name="selected_backends" value="opencl-backend" />
       <env name="TORNADO_SDK" value="$PROJECT_DIR$/bin/sdk" />
       <env name="JAVA_HOME" value="$PROJECT_DIR$/etc/dependencies/TornadoVM-graal-jdk-21/graalvm-community-openjdk-21.0.1+12.1" />
     </envs>
     <option name="SDK_HOME" value="" />
-    <option name="SDK_NAME" value="Python 3.10" />
+    <option name="SDK_NAME" value="Python 3.9 (tornado)" />
     <option name="WORKING_DIRECTORY" value="$PROJECT_DIR$" />
     <option name="IS_MODULE_SDK" value="false" />
     <option name="ADD_CONTENT_ROOTS" value="true" />
@@ -27,4 +27,4 @@
     <option name="INPUT_FILE" value="" />
     <method v="2" />
   </configuration>
-</component>
+</component>
\ No newline at end of file
diff --git a/.build/_internal_TornadoVM_Maven-cleanAndinstall.run.xml b/.build/_internal_TornadoVM_Maven-cleanAndinstall.run.xml
index 908ce38c8..dcf22bcb0 100644
--- a/.build/_internal_TornadoVM_Maven-cleanAndinstall.run.xml
+++ b/.build/_internal_TornadoVM_Maven-cleanAndinstall.run.xml
@@ -5,17 +5,18 @@
         <MavenGeneralSettings>
           <option name="alwaysUpdateSnapshots" value="false" />
           <option name="checksumPolicy" value="NOT_SET" />
+          <option name="customMavenHome" value="$PROJECT_DIR$/etc/dependencies/TornadoVM-jdk21/apache-maven-3.9.3" />
           <option name="emulateTerminal" value="true" />
           <option name="failureBehavior" value="NOT_SET" />
           <option name="localRepository" value="" />
-          <option name="mavenHome" value="$PROJECT_DIR$/etc/dependencies/apache-maven-3.9.3" />
+          <option name="mavenHome" value="$PROJECT_DIR$/etc/dependencies/TornadoVM-jdk21/apache-maven-3.9.3" />
+          <option name="mavenHomeTypeForPersistence" value="CUSTOM" />
           <option name="nonRecursive" value="false" />
           <option name="outputLevel" value="INFO" />
           <option name="printErrorStackTraces" value="false" />
           <option name="showDialogWithAdvancedSettings" value="false" />
           <option name="threads" />
           <option name="useMavenConfig" value="true" />
-          <option name="usePluginRegistry" value="false" />
           <option name="userSettingsFile" value="" />
           <option name="workOffline" value="false" />
         </MavenGeneralSettings>
@@ -33,10 +34,11 @@
               <option value="install" />
             </list>
           </option>
+          <option name="multimoduleDir" />
           <option name="pomFileName" />
           <option name="profilesMap">
             <map>
-              <entry key="graal-jdk-21" value="true" />
+              <entry key="jdk21" value="true" />
               <entry key="opencl-backend" value="true" />
             </map>
           </option>

Shall we add an external repo that pulls/builds these config files under demand?

[jjfumero]

The build is till specific to OpenCL, shall we keep the name?

[stratika]

but, in the instructions I have added the text how to extend for SPIRV and PTX. so the same application is working, it is not OpenCL-specific. the default configuration is OpenCL because it is compatible to most of the target hardware devices.

[jjfumero]

What if we don't use the same JDK?

[stratika]

It seems to be working, but user must be careful to define the same JAVA_HOME when TornadoVM is built and run.

[jjfumero]

It works with a bit of work in custom configuration. Keeping in mind that The JAVA_HOME selected during the build must be the same as the one selected for the launch.

I suggest to move forward with this PR, and have an extension of the PR to generate the xml config files as part of a new option with the TornadoVM script. Something like tornado --ideinit. I recall Graal used to have a similar approach.

[stratika]

It works with a bit of work in custom configuration. Keeping in mind that The JAVA_HOME selected during the build must be the same as the one selected for the launch.

I suggest to move forward with this PR, and have an extension of the PR to generate the xml config files as part of a new option with the TornadoVM script. Something like tornado --ideinit. I recall Graal used to have a similar approach.

yes, makes sense to me. I am not also a fun of having user-specific configurations that are being tracked by git vcs.

[mairooni]

LGTM

[stratika]

thank you, I fixed an inconsistent name of file in the docs and will merge it. I have prepared a follow-up PR to implement the generation of the xml files for IDE so that they will not be in the repository.