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

[Doug Simon]

> On 08 Apr 2016, at 20:31, Christian Thalinger <christian.thalinger at oracle.com> wrote:
> 
> 
>> On Apr 7, 2016, at 11:59 PM, Volker Simonis <volker.simonis at gmail.com> wrote:
>> 
>> On Thu, Apr 7, 2016 at 6:59 PM, Christian Thalinger
>> <christian.thalinger at oracle.com> wrote:
>>> 
>>> On Apr 7, 2016, at 2:22 AM, Volker Simonis <volker.simonis at gmail.com> wrote:
>>> 
>>> 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?
>>> 
>>> 
>>> Correct.
>>> 
>>> 
>>> 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

The most up-to-date instructions are at https://github.com/graalvm/graal-core/blob/master/README.md which suggest to use https://github.com/graalvm/mx.git. The instructions on https://wiki.openjdk.java.net/display/Graal/Main are out dated and scheduled for removal very soon.


>>> 
>>> 
>>> Since the review the mx repository got moved to github.  That’s the one you
>>> want to use.
>>> 
>>> 
>>> 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?
>>> 
>>> 
>>> I have never tried to have the output directory not in the source directory
>>> and mx might not support this.  But it’s not really necessary because
>>> everything goes into build/ by default anyway.  If you really want to have a
>>> separate output directory I suppose we could add an option to mx.
>>> 
>> 
>> Hi Christian,
>> 
>> thanks a lot for your explanation. I've never tried WITH the output
>> directory in the source tree :) I have my source repositories on a
>> network share and on every platform I configure and build from the
>> shared sources into a local directory.
>> 
>> That said, I've tried to configure and build INTO the source directory
>> and called 'mx eclipseinit' afterwards. That worked as described and
>> the created project worked quite nicely. But after playing around a
>> little bit, I found the following points:
>> 
>> - the project settings are hard-wired for linux-x86_64
>> - so it makes no difference if I configure and build on linux-ppc64,
>> the generated project still tries to get the generated files from
>> 'PARENT-5-PROJECT_LOC/build/linux-x86_64-normal-server-slowdebug'
>> which will apparently not work on any other platform.
> 
> That is half-correct.  It’s not hardcoded but it picks up the platform you are running mx on.  So, if you had a separate repository for ppc64 and run mx on the ppc64 host it should work.
> 
> I mean, there is no real solution to that problem, right?  You can only have one generated directory to be included.

In general, the mx support for native HotSpot development is somewhat limited (compared to Java development) and x64 focused given the history and resources of the project. That said, we’re open to work with you on any pull requests you care to submit.

> 
>> - the same is true for the preprocessor defines. They are hard wired
>> in ".mx.jvmci/hotspot/templates/eclipse/cproject". I don't actually
>> understand why you are creating distinct release, fastdebug and
>> slowdebug projects at all
> 
> The main reason for the different configurations is because the generated directory is different.
> 
>> , if all of them have the same settings (e.g.
>> ASSERT and DEBUG is also defined for server-release).
> 
> This is odd and sounds like a bug.  Doug?  Ah!  There is only one template:

Yes, the hotspot Eclipse configs generated by mx are quite inflexible currently.

> 
> $ find .mx.jvmci/hotspot/templates/
> .mx.jvmci/hotspot/templates/
> .mx.jvmci/hotspot/templates/eclipse
> .mx.jvmci/hotspot/templates/eclipse/cproject
> .mx.jvmci/hotspot/templates/eclipse/settings
> .mx.jvmci/hotspot/templates/eclipse/settings/org.eclipse.cdt.core.prefs
> .mx.jvmci/hotspot/templates/eclipse/settings/org.eclipse.cdt.ui.prefs
> .mx.jvmci/hotspot/templates/eclipse/settings/org.eclipse.core.runtime.prefs
> 
> A much bigger problem is this:
> 
> $ grep TARGET .mx.jvmci/hotspot/templates/eclipse/project
>                                                                         <listOptionValue builtIn="false" value="TARGET_ARCH_x86=1"/>
>                                                                         <listOptionValue builtIn="false" value="TARGET_COMPILER_gcc=1"/>
>                                                                         <listOptionValue builtIn="false" value="TARGET_OS_FAMILY_linux=1"/>
>                                                                         <listOptionValue builtIn="false" value="TARGET_OS_ARCH_linux_x86=1"/>
>                                                                         <listOptionValue builtIn="false" value="TARGET_ARCH_MODEL_x86_64=1"/>
> 
> Doug, can we change that to actually use the right defines?

Possibly. The current “templates" were created by simply copying someones manually set up configuration. For someone who understands CDT projects well, this probably wouldn’t be hard to fix.

-Doug