C/C++ IDE support for HotSpot

Mikael Gerdin mikael.gerdin at oracle.com
Fri Mar 24 08:47:05 UTC 2017

Hi Robbin,

On 2017-03-24 09:02, Robbin Ehn wrote:
> Hi, again,
> On 03/24/2017 08:58 AM, Robbin Ehn wrote:
>> Hi Mikeal,
>> On 03/22/2017 05:20 PM, Erik Österlund wrote:
>>> Hi Mikael,
>>> In my workflow I use emacs with rtags for snytax awareness.
>>> With your cmake patch, I could easily generate the cmake files and
>>> run cmake  with -DCMAKE_EXPORT_COMPILE_COMMANDS to generate the
>>> compiler_commands.json file used by rtags
>>> to understand how the code fits together, and feed it to rdm.
>>> Everything worked out of the box.
>> I also use rtags, but with vim.
>>> With these changes it was faster than ever to setup a good
>>> emacs-based project for hotspot development. So I encourage these
>>> changes!
>> I have not tested this, but it must be faster, since now I compile the
>> source twice, once with gcc and once with clang for rtags.
> I have still gotten my morning coffee, this step I have to do anyways of
> course.
>> Can cmake do incremental updates to compiler_command.json file, would
>> be awesome if so? (Erik?)
> This is what I need, now I can't do incremental builds if change any
> flags or add files.

I'm not sure how the generation of compiler_command.json works but to 
refresh the CMakeLists.txt file you have to invoke the 
hotspot-cmake-project make target again. This should pick up new files 
or flags from the build system.

There is a way to add dependencies on build system variables so that the 
refresh would only actuallly run when needed but I couldn't figure that 
out so for now the CMakeLists generation is .PHONY-target.


> /Robbin
>> Thanks for doing this!
>> /Robbin
>>> Thanks,
>>> /Erik
>>> On 2017-03-22 15:21, Mikael Gerdin wrote:
>>>> Hi all,
>>>> I've finally grown tired of manually setting up a hand crafted
>>>> Eclipse CDT configuration for the JVM sources and decided to share
>>>> my progress towards improving the
>>>> overall situation for JVM developers.
>>>> To achieve better IDE support without having to add project
>>>> generators for all different kinds of past or future IDEs I've
>>>> decided to try to leverage CMake to do project
>>>> generation.
>>>> The idea is to have the JDK build system generate a CMakeLists.txt
>>>> describing all the include paths and definitions required by an IDE
>>>> to interpret the sources correctly.
>>>> Several modern IDEs natively support CMake but we can also rely on
>>>> the fact that the CMake build system has the ability to generate
>>>> projects for a number of different
>>>> IDEs. For information about which generators CMake supports see
>>>> https://cmake.org/cmake/help/v3.5/manual/cmake-generators.7.html
>>>> for your CMake version.
>>>> To try this out check out (heh) my branch "JDK-8177329-cmake-branch"
>>>> in the jdk10/sandbox forest:
>>>> http://hg.openjdk.java.net/jdk10/sandbox/branches
>>>> So far I've only made changes in the toplevel and hotspot repositories.
>>>> I've written a short readme in the repo:
>>>> http://hg.openjdk.java.net/jdk10/sandbox/raw-file/JDK-8177329-cmake-branch/README-cmake.html
>>>> It would be great if people tried this out to see if it works on
>>>> their setup but I don't expect it to work on Windows without
>>>> changing the makefile to do path conversion.
>>>> If we can make this work properly then perhaps we can get rid of the
>>>> Visual Studio generator and rely on CMake to generate VS projects.
>>>> It would also be great if someone from build-dev could give me some
>>>> hints about how to do the file writing and "vardeps" thing properly.
>>>> Thanks
>>>> /Mikael

More information about the build-dev mailing list