RFR (S): 8139921: add mx configuration files to support HotSpot IDE configuration generation

[Volker Simonis]

Hi Christian,

I'd like to try this but I couldn't figure out how it works.
I don't have any experience with Graal/Truffel/JVMCI but as far as I
understood the creation of an Eclipse project should work equally well
for a vanilla hospot repository, right?

The first question is where to get mx from (there's different
information in the Wiki and this email thread for example) ?

https://bitbucket.org/allr/mx
oder
https://github.com/graalvm/mx.git

Now let's say I cloned the right mx version. How do I use it?
Let's say I have a vanilla jdk9 forest under /share/OpenJDK/jdk9
I create an output directory under /share/OpenJDK/output-jdk9-dbg and
from there I call configure and build the images:

cd /share/OpenJDK/output-jdk9-dbg
bash /share/OpenJDK/jdk9/configure --with-boot-jdk=..
--with-debug-level=slowdebug
make images

Taking this scenario, from which directory am I supposed to call 'mx
ideinit', where will the Eclipse project be created at and how is mx
supposed to find my configuration (i.e. platform) and generated files?

Thanks a lot and best regards,
Volker


On Wed, Nov 11, 2015 at 1:42 AM, Christian Thalinger
<christian.thalinger at oracle.com> wrote:
> [This is kind of a long email but contains pictures :-)]
>
> https://bugs.openjdk.java.net/browse/JDK-8139921
> http://cr.openjdk.java.net/~twisti/8139921/webrev/
>
> In order to make the IDE experience more pleasant now that JEP 243 is integrated we would like to use mx (https://bitbucket.org/allr/mx) for IDE configuration generation.  For this we have to integrate a few mx support files into the hotspot repository.
>
> The mx support files will be under a dot-directory:
>
> $ hg st --all .mx.jvmci/
> C .mx.jvmci/.project
> C .mx.jvmci/.pydevproject
> C .mx.jvmci/eclipse-settings/org.eclipse.jdt.core.prefs
> C .mx.jvmci/hotspot/templates/eclipse/cproject
> C .mx.jvmci/hotspot/templates/eclipse/settings/org.eclipse.cdt.core.prefs
> C .mx.jvmci/hotspot/templates/eclipse/settings/org.eclipse.cdt.ui.prefs
> C .mx.jvmci/hotspot/templates/eclipse/settings/org.eclipse.core.runtime.prefs
> C .mx.jvmci/mx_jvmci.py
> C .mx.jvmci/suite.py
>
> mx itself is and will stay an external tool.  Some documentation on how to use it can be found here:
>
> https://wiki.openjdk.java.net/display/Graal/Instructions
> https://wiki.openjdk.java.net/display/Graal/Eclipse
>
> It basically boils down to:
>
> $ mx ideinit
>
> and importing the configuration into your favorite IDE.
>
> This would give every developer the same view of the source code and we can also enforce code-style guidelines.
>
> Here is how the imported projects look like in Eclipse:
>
>
>
> This is most helpful for Compiler engineers who work on the JVMCI but there is value for others too.
>
> Notice the “hotspot:*” projects at the top?  These are projects for different HotSpot configurations.  The main advantage here is that these include the generated files directory (if the configuration exists and the files are built).  I only configured and built “release” so these can been seen, fastdebug is empty:
>
>
>
> This makes it possible for Eclipse to find generated source code.  Very helpful.  For example, JVMTI.  First, jvmtiUtils.hpp from the fastdebug configuration:
>
>
>
> and here is the release one:
>
>
>
> mx has lots of other commands but most of them are not really useful for us.  The only ones worth mentioning besides ideinit are findbugs and checkstyle.
>
> findbugs runs FindBugs (doh!) on all Java projects that mx knows about:
>
> cthaling at macbook:~/ws/8139921/hotspot$ mx findbugs
> Scanning archives (15 / 30)
> 2 analysis passes to perform
> Pass 1: Analyzing classes (524 / 524) - 100% complete
> Pass 2: Analyzing classes (305 / 305) - 100% complete
> Done with analysis
> Calculating exit code...
> Exit code set to: 0
>
> checkstyle checks the Java projects against some predefined style.  This is particularly helpful for people who don’t use an IDE or to make sure everything matches the style after applying an external patch:
>
> cthaling at macbook:~/ws/8139921/hotspot$ mx checkstyle
> Running Checkstyle on /Users/cthaling/ws/8139921/hotspot/src/jdk.vm.ci/share/classes/jdk.vm.ci.runtime/src using /Users/cthaling/ws/8139921/hotspot/src/jdk.vm.ci/share/classes/jdk.vm.ci.service/.checkstyle_checks.xml...
> /Users/cthaling/ws/8139921/hotspot/src/jdk.vm.ci/share/classes/jdk.vm.ci.runtime/src/jdk/vm/ci/runtime/JVMCI.java:33: 'static' modifier out of order with the JLS suggestions.
>
> or:
>
> cthaling at macbook:~/ws/8139921/hotspot$ mx checkstyle
> Running Checkstyle on /Users/cthaling/ws/8139921/hotspot/src/jdk.vm.ci/share/classes/jdk.vm.ci.runtime/src using /Users/cthaling/ws/8139921/hotspot/src/jdk.vm.ci/share/classes/jdk.vm.ci.service/.checkstyle_checks.xml...
> /Users/cthaling/ws/8139921/hotspot/src/jdk.vm.ci/share/classes/jdk.vm.ci.runtime/src/jdk/vm/ci/runtime/JVMCI.java:43: Name 'FOO' must match pattern '^[a-z][a-zA-Z0-9]*$'.
>
> That’s all, folks!