Hi Erik,

> On 14 Sep 2018, at 19:21, Erik Joelsson <erik.joels...@oracle.com> wrote:
> 
>>> Main.gmk:888: I think you meant to add test-compile-commands here, which 
>>> also requires you to define that target.
>> Fixed, the tests are now invoked from a top-level target. I also added a 
>> second test to ensure that the no-build-libraries property of this actually 
>> stays intact.
> This is ok, but the test will fail unless run from a clean output dir. This 
> should probably be noted in a comment at least.

Yes, good point, I tried briefly to include a clean as a prerequisite target to 
the test, but it refused to execute sequentially. But perhaps it’s good enough 
with a comment, added one.

>>> In Awt2dLibraries.gmk, I think lines 733 and 735 needs to be fixed as well. 
>>> Using FindLib is generally a good idea for this. I suspect there may be 
>>> more such instances sprinkled around the makefiles.
>> Only fixed the last one, I think the first one is ok as is?
> The first one is sort of OK, but it's a questionable construct as the 
> $(BUILD_LIBAWT_XAWT) variable may contain additional targets. We used to do 
> it that way but these days I prefer the more explicit and precise FindLib. In 
> this particular case you get a non needed dependency added when running 
> compile-commands with ENABLE_HEADLESS_ONLY=true, which will not really affect 
> anything so it doesn't really matter.

Yeah I certainly agree, but a quick grep shows that there’s about 50 such 
constructs present right now. I wouldn’t mind cleaning those up, but perhaps 
that should be in a separate change?

> Otherwise this looks good now.

Thanks, I’ll include the latest webrevs with a comment added:

Incremental: http://cr.openjdk.java.net/~rwestberg/8210459/webrev.01-02/
Full: http://cr.openjdk.java.net/~rwestberg/8210459/webrev.02/

Best regards,
Robin

> 
> /Erik
>> Webrev (incremental): 
>> http://cr.openjdk.java.net/~rwestberg/8210459/webrev.00-01/
>> Webrev (full): http://cr.openjdk.java.net/~rwestberg/8210459/webrev.01/
>> Testing: tier1, builds-tier5
>> 
>> Best regards,
>> Robin
>> 
>>> /Erik
>>> 
>>> 
>>> On 2018-09-10 06:36, Robin Westberg wrote:
>>>> Hi all,
>>>> 
>>>> Please review the following change that adds support for generating 
>>>> compile_commands.json as a top-level make target. This is a popular format 
>>>> for describing how to compile object files for a project, and is defined 
>>>> in [1]. This file can be used directly by IDEs such as Visual Studio Code 
>>>> and CLion as well as "language servers" such as cquery [2] and rtags [3].
>>>> 
>>>> While it’s currently possible to generate this file as part of a full 
>>>> build (using tools such as Bear [4], or simply parsing .cmdline files), 
>>>> this change aims to make it possible to generate the compile commands data 
>>>> without actually compiling the object files. This means that it’s for 
>>>> example possible to start using an IDE fairly quickly on freshly cloned 
>>>> source, instead of having to wait for a full build to complete.
>>>> 
>>>> This was originally inspired by the work done in [5] by Mikael Gerdin and 
>>>> Erik Joelsson, but has been through a few revisions since then. Erik has 
>>>> also provided a lot of assistance with the current version, thanks Erik!
>>>> 
>>>> Issue: https://bugs.openjdk.java.net/browse/JDK-8210459
>>>> Webrev: http://cr.openjdk.java.net/~rwestberg/8210459/webrev.00/
>>>> Testing: tier1, builds-tier5
>>>> 
>>>> Best regards,
>>>> Robin
>>>> 
>>>> [1] https://clang.llvm.org/docs/JSONCompilationDatabase.html
>>>> [2] https://github.com/cquery-project/cquery
>>>> [3] https://github.com/Andersbakken/rtags
>>>> [4] https://github.com/rizsotto/Bear
>>>> [5] 
>>>> http://mail.openjdk.java.net/pipermail/hotspot-dev/2017-March/026354.html

Reply via email to