C/C++ IDE support for HotSpot

[Mikael Gerdin]

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.



/Mikael

>
> /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
>>>