Re: CMake replacing Autotools?

Hi Christoph, > On 19 Mar 2021, at 00:00, Christoph Grüninger wrote: > > ... > > 2. More choices to actually build the project: Use integrated build > tools of IDEs (Visual Studio, Xcode) or use Ninja, which is faster than > gmake > > ... > > 4. CMake is better supported by IDEs like Visual

Integrated: 8263667: Avoid running GitHub actions on branches named pr/*

On Tue, 16 Mar 2021 10:53:06 GMT, Robin Westberg wrote: > When the Skara feature "dependent pull requests" is activated for the JDK > repository, branches with the name "pr/" will start to appear. These > will not be synced into personal fo

RFR: 8263667: Avoid running GitHub actions on branches named pr/*

When the Skara feature "dependent pull requests" is activated for the JDK repository, branches with the name "pr/" will start to appear. These will not be synced into personal forks by the Skara sync command, but if they are synced manually, we should avoid running GitHub actions workflows on

Re: RFR: 8258477: Pre-submit testing using GitHub Actions should merge changes from target branch

On Wed, 16 Dec 2020 10:47:50 GMT, Robin Westberg wrote: > Normally when running GitHub Actions on a pull request, what is checked out > is the merge of the pull request with the latest changes on the target > branch. This ensure that what is tested is as close as possibl

Re: RFR: 8258477: Pre-submit testing using GitHub Actions should merge changes from target branch

g it, and just use the commit in the pull request as-is. Best regards, Robin > > Thanks, Thomas > > > On Wed, Dec 16, 2020 at 11:55 AM Robin Westberg > wrote: > >> Normally when running GitHub Actions on a pull request, what is checked >> out is the merge of the

RFR: 8258477: Pre-submit testing using GitHub Actions should merge changes from target branch

Normally when running GitHub Actions on a pull request, what is checked out is the merge of the pull request with the latest changes on the target branch. This ensure that what is tested is as close as possible to what will actually be the result of integrating said pull request. In our use

Re: RFR: 8256747: GitHub Actions: decouple the hotspot build-only jobs from Linux x64 testing [v2]

On Thu, 26 Nov 2020 16:25:35 GMT, Magnus Ihse Bursie wrote: >>> That sounds very good indeed! I did not think it was possible for Skara to >>> access the Checks area, but if it does, it's really where this belong. >> >> I've tried this out a bit in the playground now - perhaps something like

Re: RFR: 8256747: GitHub Actions: decouple the hotspot build-only jobs from Linux x64 testing [v2]

On Mon, 23 Nov 2020 11:54:48 GMT, Magnus Ihse Bursie wrote: > That sounds very good indeed! I did not think it was possible for Skara to > access the Checks area, but if it does, it's really where this belong. I've tried this out a bit in the playground now - perhaps something like this:

Re: RFR: 8257056: Submit workflow should apt-get update to avoid package installation errors

On Wed, 25 Nov 2020 08:56:33 GMT, Aleksey Shipilev wrote: > For example, current jobs fail with: > > Get:13 http://azure.archive.ubuntu.com/ubuntu focal/main amd64 libxtst-dev > amd64 2:1.2.3-1 [15.2 kB] > E: Failed to fetch >

Re: gh actions fail on linux x64 when fetching libsound

Hi Aleksey, > On 25 Nov 2020, at 09:49, Aleksey Shipilev wrote: > > On 11/25/20 9:45 AM, Thomas Stüfe wrote: >> "E: Failed to fetch >> http://azure.archive.ubuntu.com/ubuntu/pool/main/a/alsa-lib/libasound2-dev_1.2.2-2.1ubuntu2.1_amd64.deb >> 404 Not Found [IP: 52.147.219.192 80]" >>

Integrated: 8256747: GitHub Actions: decouple the hotspot build-only jobs from Linux x64 testing

On Fri, 20 Nov 2020 14:24:12 GMT, Robin Westberg wrote: > Currently Linux x64 testing in GitHub Actions depends on a few non-relevant > hotspot build-only jobs (such as zero) that prevents testing from being run > if those build were to fail. As the tests only require the x6

Re: RFR: 8256747: GitHub Actions: decouple the hotspot build-only jobs from Linux x64 testing [v2]

On Mon, 23 Nov 2020 09:59:39 GMT, Aleksey Shipilev wrote: >> I personally think I prefer to just use a single column for the additional >> cross compile builds, because the table becomes very big otherwise (and the >> rows get split up). You still see the full name of the build in case >>

Re: RFR: 8256747: GitHub Actions: decouple the hotspot build-only jobs from Linux x64 testing [v2]

On Fri, 20 Nov 2020 17:31:08 GMT, Aleksey Shipilev wrote: >> Robin Westberg has updated the pull request incrementally with one >> additional commit since the last revision: >> >> Improve naming, fix style issues > > .github/workflows/submit.yml line 526:

Re: RFR: 8256747: GitHub Actions: decouple the hotspot build-only jobs from Linux x64 testing [v2]

On Fri, 20 Nov 2020 17:35:12 GMT, Aleksey Shipilev wrote: >> Looks good! A few minor nits, if you want to address them. > > Ah wait, I now see "Linux additional" is the column name in testing table, > because it is the name of the job! Eh... It was nicer to have columns per > arch. Does it

Re: RFR: 8256747: GitHub Actions: decouple the hotspot build-only jobs from Linux x64 testing [v3]

feedback, we should separate > these other builds into a different job. > > To reduce duplicated steps, all the existing hotspot-only builds have been > consolidated into a single job. Robin Westberg has updated the pull request incrementally with one additional commit since the last

Re: RFR: 8256747: GitHub Actions: decouple the hotspot build-only jobs from Linux x64 testing [v2]

On Fri, 20 Nov 2020 14:39:54 GMT, Aleksey Shipilev wrote: >> Robin Westberg has updated the pull request incrementally with one >> additional commit since the last revision: >> >> Improve naming, fix style issues > > .github/workflows/submit.yml line 380: >

Re: RFR: 8256747: GitHub Actions: decouple the hotspot build-only jobs from Linux x64 testing [v2]

feedback, we should separate > these other builds into a different job. > > To reduce duplicated steps, all the existing hotspot-only builds have been > consolidated into a single job. Robin Westberg has updated the pull request incrementally with one additional commit since the l

RFR: 8256747: GitHub Actions: decouple the hotspot build-only jobs from Linux x64 testing

Currently Linux x64 testing in GitHub Actions depends on a few non-relevant hotspot build-only jobs (such as zero) that prevents testing from being run if those build were to fail. As the tests only require the x64 release and debug builds to run and provide interesting feedback, we should

Integrated: 8256393: Github Actions build on Linux should define OS and GCC versions

On Mon, 16 Nov 2020 12:51:25 GMT, Robin Westberg wrote: > We should be more explicit about OS and compiler versions used in the GitHub > Actions builds, to avoid problems caused by unexpected changes to the > defaults. This patch changes the OS and GCC versions used from ubun

Re: RFR: 8256393: Github Actions build on Linux should define OS and GCC versions [v3]

ometime soon) / default > (currently 9.3.0) to 20.04 / 10.2.0. Robin Westberg has updated the pull request incrementally with one additional commit since the last revision: Use proper package version - Changes: - all: https://git.openjdk.java.net/jdk/pull/1225/files

Re: RFR: 8256393: Github Actions build on Linux should define OS and GCC versions [v2]

On Mon, 16 Nov 2020 15:12:25 GMT, Magnus Ihse Bursie wrote: >> .github/workflows/submit.yml line 190: >> >>> 188: run: | >>> 189: sudo apt-get install libxrandr-dev libxtst-dev libcups2-dev >>> libasound2-dev >>> 190: sudo update-alternatives --install /usr/bin/gcc

Re: RFR: 8256393: Github Actions build on Linux should define OS and GCC versions [v2]

ometime soon) / default > (currently 9.3.0) to 20.04 / 10.2.0. Robin Westberg has updated the pull request incrementally with one additional commit since the last revision: Select gcc/g++ package versions explicitly - Changes: - all: https://git.openjdk.java.net/jdk/pull/1225/files

Re: RFR: 8256393: Github Actions build on Linux should define OS and GCC versions

On Mon, 16 Nov 2020 13:51:29 GMT, Erik Joelsson wrote: >> We should be more explicit about OS and compiler versions used in the GitHub >> Actions builds, to avoid problems caused by unexpected changes to the >> defaults. This patch changes the OS and GCC versions used from ubuntu-latest >>

Re: RFR: 8256393: Github Actions build on Linux should define OS and GCC versions

On Mon, 16 Nov 2020 13:13:52 GMT, Aleksey Shipilev wrote: >> We should be more explicit about OS and compiler versions used in the GitHub >> Actions builds, to avoid problems caused by unexpected changes to the >> defaults. This patch changes the OS and GCC versions used from ubuntu-latest >>

RFR: 8256393: Github Actions build on Linux should define OS and GCC versions

We should be more explicit about OS and compiler versions used in the GitHub Actions builds, to avoid problems caused by unexpected changes to the defaults. This patch changes the OS and GCC versions used from ubuntu-latest (currently 18.04, but will change to 20.04 sometime soon) / default

Integrated: 8256354: Github Action build on Windows should define OS and MSVC versions

On Fri, 13 Nov 2020 17:26:28 GMT, Robin Westberg wrote: > We should be more explicit about OS and compiler versions used in the GitHub > Actions builds, to avoid problems caused by unexpected changes to the > defaults. This patch changes the OS and MSVC versions used from latest >

Integrated: 8256277: Github Action build on macOS should define OS and Xcode versions

On Fri, 13 Nov 2020 11:48:31 GMT, Robin Westberg wrote: > We should be more explicit about OS and compiler versions used in the GitHub > Actions builds, to avoid problems caused by unexpected changes to the > defaults. This patch changes the OS and Xcode versions used from latest >

RFR: 8256354: Github Action build on Windows should define OS and MSVC versions

We should be more explicit about OS and compiler versions used in the GitHub Actions builds, to avoid problems caused by unexpected changes to the defaults. This patch changes the OS and MSVC versions used from latest (currently 2019) / default (currently 14.28) to 2019 / 14.27. -

Re: RFR: 8256277: Github Action build on macOS should define OS and Xcode versions

On Fri, 13 Nov 2020 11:58:19 GMT, Aleksey Shipilev wrote: >> We should be more explicit about OS and compiler versions used in the GitHub >> Actions builds, to avoid problems caused by unexpected changes to the >> defaults. This patch changes the OS and Xcode versions used from latest >>

RFR: 8256277: Github Action build on macOS should define OS and Xcode versions

We should be more explicit about OS and compiler versions used in the GitHub Actions builds, to avoid problems caused by unexpected changes to the defaults. This patch changes the OS and Xcode versions used from latest (currently 10.15) / default (currently 12.0) to 10.15 / 11.3.1.

Re: RFR: 8256127: Add cross-compiled foreign architectures builds to submit workflow [v6]

On Fri, 13 Nov 2020 10:54:01 GMT, Aleksey Shipilev wrote: >> Looks good! I did a similar attempt at cross building a while ago, but never >> got around to finishing it, so it's nice to see it materializing! I do have >> a general comment on reducing the amount of duplicated content though.

Re: RFR: 8256127: Add cross-compiled foreign architectures builds to submit workflow [v6]

On Thu, 12 Nov 2020 06:50:08 GMT, Aleksey Shipilev wrote: >> It is >> [possible](https://github.com/openjdk/jdk/blob/master/doc/building.md#creating-and-using-sysroots-with-qemu-deboostrap) >> to efficiently cross-compile to foreign architectures on current GH actions >> that are driven by

Re: RFR: 8255352: Archive important test outputs in submit workflow

On Fri, 23 Oct 2020 17:18:57 GMT, Aleksey Shipilev wrote: > Currently, we are only archiving `build/*/test-results`. But hs_errs, > replays, and test outputs are actually in `build/*/test-support`! Which means > once any test fails, we only have the summary of the run, not the bits that >

Re: RFR: 8255373: Submit workflow artifact name is always "test-results_.zip"

On Sat, 24 Oct 2020 08:35:31 GMT, Aleksey Shipilev wrote: > The output for the `prerequisites` step is `bundle_id: ${{ > steps.check_bundle_id.outputs.bundle_id }}`, but there is no > `check_bundle_id` step name to properly reference. Then `artifacts` should > actually need `prerequisites` to

Re: RFR: 8254282: Add Linux x86_32 builds to submit workflow

On Mon, 12 Oct 2020 12:46:57 GMT, Aleksey Shipilev wrote: > Building x86_32 usually exposes 32/64 cleanliness problems early. Since > 32-bit builds break often, it might make sense > to add them to submit workflow. The x86_32 might not be widely deployed by > itself, but 32/64 bit cleanliness

Re: RFR: 8254173: Add Zero, Minimal hotspot targets to submit workflow [v3]

On Thu, 8 Oct 2020 07:20:39 GMT, Aleksey Shipilev wrote: >> Zero VM and Minimal VM builds are routinely discovering the problems with >> internal Hotspot dependencies. Mostly because >> they turn off the whole lot of VM features, and every path that is not >> guarded by a feature #ifdef or

Re: RFR: 8254175: Build no-pch configuration in debug mode for submit checks [v2]

On Thu, 8 Oct 2020 07:19:21 GMT, Aleksey Shipilev wrote: >> no-pch configuration is supposed to expose missing include dependencies. But >> currently it runs with default (release) >> bits, which misses symbols hidden in debug code. We should consider building >> it in debug mode. >> Attention

Re: RFR: 8254173: Add Zero, Minimal hotspot targets to submit workflow [v2]

On Thu, 8 Oct 2020 07:12:12 GMT, Aleksey Shipilev wrote: >> That makes sense. We should change the order in #547 then first? So the >> final thing would be: >> >> - build release >> - build debug >> - build hotspot no-pch debug >> - build hotspot zero no-pch debug >> - build hotspot minimal

Re: RFR: 8254173: Add Zero, Minimal hotspot targets to submit workflow [v2]

On Wed, 7 Oct 2020 16:28:17 GMT, Aleksey Shipilev wrote: >> Zero VM and Minimal VM builds are routinely discovering the problems with >> internal Hotspot dependencies. Mostly because >> they turn off the whole lot of VM features, and every path that is not >> guarded by a feature #ifdef or

Integrated: 8254054: Pre-submit testing using GitHub Actions should not use the deprecated set-env command

On Tue, 6 Oct 2020 06:39:55 GMT, Robin Westberg wrote: > The `set-env` command was recently deprecated in favor of a different method > of setting environment variables, due to a > security vulnerability [1]. The vulnerability does not affect our usage of > GitHub Actions, b

RFR: 8254054: Pre-submit testing using GitHub Actions should not use the deprecated set-env command

The `set-env` command was recently deprecated in favor of a different method of setting environment variables, due to a security vulnerability [1]. The vulnerability does not affect our usage of GitHub Actions, but we should nevertheless update to avoid the associated deprecation warnings. [1]

Integrated: 8253865: Pre-submit testing using GitHub Actions does not detect failures reliably

On Wed, 30 Sep 2020 16:58:25 GMT, Robin Westberg wrote: > The pre-submit test definitions utilizing GitHub Actions can sometimes report > success even when there are failing > tests. The failure detection depended on make returning a non-zero exit code > on failures, which doesn't

RFR: 8253865: Pre-submit testing using GitHub Actions does not detect failures reliably

The pre-submit test definitions utilizing GitHub Actions can sometimes report success even when there are failing tests. The failure detection depended on make returning a non-zero exit code on failures, which doesn't seem to work. To properly determine test outcome we should check the

Integrated: 8253424: Add support for running pre-submit testing using GitHub Actions

On Mon, 21 Sep 2020 13:32:09 GMT, Robin Westberg wrote: > A few days ago I posted an initial version of the necessary configuration > required to run pre-submit build and tests > for JDK main-line contributions using GitHub Actions [2] and the free tier > [3] available to ever

Re: RFR: 8253424: Add support for running pre-submit testing using GitHub Actions [v7]

ards, > Robin [1] > https://mail.openjdk.java.net/pipermail/jdk-dev/2020-September/004736.html [2] > https://github.com/features/actions [3] > https://docs.github.com/en/actions/getting-started-with-github-actions/about-github-actions#usage-limits > [4] > https://docs.github.com/en/a

Re: RFR: 8253424: Add support for running pre-submit testing using GitHub Actions [v6]

ards, > Robin [1] > https://mail.openjdk.java.net/pipermail/jdk-dev/2020-September/004736.html [2] > https://github.com/features/actions [3] > https://docs.github.com/en/actions/getting-started-with-github-actions/about-github-actions#usage-limits > [4] > https://docs.github.com/en/a

Re: RFR: 8253424: Add support for running pre-submit testing using GitHub Actions

On Wed, 23 Sep 2020 17:55:23 GMT, Robin Westberg wrote: >> The version-numbers file (which is also a shared properties style file) is >> not using quotes for values, which is fine >> as long as there are no spaces. I believe if you read it as a properties >> file, you

Re: RFR: 8253424: Add support for running pre-submit testing using GitHub Actions [v5]

ards, > Robin [1] > https://mail.openjdk.java.net/pipermail/jdk-dev/2020-September/004736.html [2] > https://github.com/features/actions [3] > https://docs.github.com/en/actions/getting-started-with-github-actions/about-github-actions#usage-limits > [4] > https://docs.github.com/en/a

Re: RFR: 8253424: Add support for running pre-submit testing using GitHub Actions [v4]

ards, > Robin [1] > https://mail.openjdk.java.net/pipermail/jdk-dev/2020-September/004736.html [2] > https://github.com/features/actions [3] > https://docs.github.com/en/actions/getting-started-with-github-actions/about-github-actions#usage-limits > [4] > https://docs.github.com/en/a

Re: RFR: 8248984: Bump minimum boot jdk to JDK 15

On Wed, 23 Sep 2020 22:47:47 GMT, Erik Joelsson wrote: >> JDK 15 is now GA. The minimum boot JDK version for mainline/JDK 16 should be >> bumped to this version. >> >> Testing: tier1-5 passed with a slightly earlier version of this change. >> Re-running tier1 now for good luck. > > @rwestberg

Re: RFR: 8253424: Add support for running pre-submit testing using GitHub Actions

On Wed, 23 Sep 2020 17:24:39 GMT, Erik Joelsson wrote: >> I added `make/conf/test-dependencies` with version numbers specified on the >> format that `jib-profiles.js` would expect. >> Actually using them from that file as well could perhaps be a separate task >> though. :) > > The

Re: RFR: 8253424: Add support for running pre-submit testing using GitHub Actions [v3]

ards, > Robin [1] > https://mail.openjdk.java.net/pipermail/jdk-dev/2020-September/004736.html [2] > https://github.com/features/actions [3] > https://docs.github.com/en/actions/getting-started-with-github-actions/about-github-actions#usage-limits > [4] > https://docs.github.com/en/a

Re: RFR: 8253424: Add support for running pre-submit testing using GitHub Actions [v2]

ards, > Robin [1] > https://mail.openjdk.java.net/pipermail/jdk-dev/2020-September/004736.html [2] > https://github.com/features/actions [3] > https://docs.github.com/en/actions/getting-started-with-github-actions/about-github-actions#usage-limits > [4] > https://docs.github.com/en/a

Re: RFR: 8253424: Add support for running pre-submit testing using GitHub Actions

On Tue, 22 Sep 2020 14:05:42 GMT, Erik Joelsson wrote: >> Sure, should not be that hard to parse something similar. The GitHub actions >> will probably need it in JSON format at >> some point, but nothing a little `sed -e '1i {' -e 's/#.*//g' -e 's/"//g' -e >> 's/(.*)=(.*)/"\1": "\2",/g' -e >>

Re: RFR: 8253424: Add support for running pre-submit testing using GitHub Actions

On Mon, 21 Sep 2020 17:22:57 GMT, Erik Joelsson wrote: >> Certainly, the prerequisites step can checkout additional repositories and >> run shell commands to extract variables to >> be used for later steps. Do we have any suitable source for these versions? >> We'll also need download links

Re: RFR: 8253424: Add support for running pre-submit testing using GitHub Actions

On Mon, 21 Sep 2020 13:59:06 GMT, Erik Joelsson wrote: >> A few days ago I posted an initial version of the necessary configuration >> required to run pre-submit build and tests >> for JDK main-line contributions using GitHub Actions [2] and the free tier >> [3] available to everyone working

RFR: 8253424: Add support for running pre-submit testing using GitHub Actions

A few days ago I posted an initial version of the necessary configuration required to run pre-submit build and tests for JDK main-line contributions using GitHub Actions [2] and the free tier [3] available to everyone working with open source repositories. I've incorporated the feedback into an

Integrated: 8252897: Minor .jcheck/conf update

On Tue, 8 Sep 2020 10:31:42 GMT, Robin Westberg wrote: > The initial version of the Skara-formatted jcheck configuration file > contained a small error, this change corrects it. > > Best regards, > Robin This pull request has now been integrated. Changeset: bf5da0c7 Author:

Re: RFR: 8252897: Minor .jcheck/conf update

On Tue, 8 Sep 2020 11:41:31 GMT, Erik Helin wrote: >> The initial version of the Skara-formatted jcheck configuration file >> contained a small error, this change corrects it. >> >> Best regards, >> Robin > > Looks good, thanks for fixing! Thanks for reviewing Erik! As this problem affects

RFR: 8252897: Minor .jcheck/conf update

The initial version of the Skara-formatted jcheck configuration file contained a small error, this change corrects it. Best regards, Robin - Commit messages: - Fix mistake in jcheck configuration file Changes: https://git.openjdk.java.net/jdk/pull/70/files Webrev:

Integrated: 8252844: Update check configuration to Skara format

On Mon, 7 Sep 2020 07:19:50 GMT, Robin Westberg wrote: > Now that the JDK main-line repository is using the Skara tooling, the jcheck > configuration file should be updated to > the new format. > Best regards, > Robin This pull request has now been integrated. Changeset:

Re: RFR: 8252844: Update check configuration to Skara format [v2]

On Mon, 7 Sep 2020 08:01:54 GMT, Erik Helin wrote: >> Robin Westberg has updated the pull request incrementally with one >> additional commit since the last revision: >> >> Apply review suggestion >> >> Co-authored-by: Erik Duveblad > &

Re: RFR: 8252844: Update check configuration to Skara format [v2]

> Now that the JDK main-line repository is using the Skara tooling, the jcheck > configuration file should be updated to > the new format. > Best regards, > Robin Robin Westberg has updated the pull request incrementally with one additional commit since the last revision:

RFR: 8252844: Update check configuration to Skara format

Now that the JDK main-line repository is using the Skara tooling, the jcheck configuration file should be updated to the new format. Best regards, Robin - Commit messages: - Initial update Changes: https://git.openjdk.java.net/jdk/pull/39/files Webrev:

Re: RFR: 8223678: Add Visual Studio Code workspace generation support (for native code)

Hi Erik, > On 31 May 2019, at 18:15, Erik Joelsson wrote: > > Hello Robin, > > On 2019-05-31 05:26, Robin Westberg wrote: >> Hi Erik, >> >>> On 29 May 2019, at 17:22, Erik Joelsson wrote: >>> >>> Thanks, looks good! >> Thanks

Re: RFR: 8223678: Add Visual Studio Code workspace generation support (for native code)

Hi Volker, > On 29 May 2019, at 16:01, Volker Simonis wrote: > > On Wed, May 29, 2019 at 3:43 PM Robin Westberg > wrote: >> >> Hi Volker, >> >>> On 28 May 2019, at 17:33, Volker Simonis wrote: >>> >>> Hi Robin, >>> >>

Re: RFR: 8223678: Add Visual Studio Code workspace generation support (for native code)

- Full: http://cr.openjdk.java.net/~rwestberg/8223678/webrev.03/ - Inc: http://cr.openjdk.java.net/~rwestberg/8223678/webrev.02-03/ Best regards, Robin > > /Erik > > On 2019-05-29 06:52, Robin Westberg wrote: >> Hi Erik, >> >> Thanks for taking a look! >> >>> On

Re: RFR: 8223678: Add Visual Studio Code workspace generation support (for native code)

t/~rwestberg/8223678/webrev.01-02/ Best regards, Robin > > /Erik > > On 2019-05-27 09:03, Robin Westberg wrote: >> Hi all, >> >> Please review this change that adds build system support for generating a >> Visual Studio Code workspace configured for work

Re: RFR: 8223678: Add Visual Studio Code workspace generation support (for native code)

exer, but ithat one is a bit tricky to configure unless you use clang for building the JDK as well. So in summary, after the summer the default indexer might be the obvious best choice, but right now it depends on which features you think are the most important I guess.. Best regards, Ro

RFR: 8223678: Add Visual Studio Code workspace generation support (for native code)

Hi all, Please review this change that adds build system support for generating a Visual Studio Code workspace configured for working with the JDK native code. It configures the default C/C++ IntelliSense Engine to allow code completion/navigation and similar features. It also configures two

Re: RFR(L/XS) : 8222414 : bring googlemock v1.8.1

Hi Igor, Looks good to me, I tried rewriting parts of an existing test to use gmock instead of a handcrafted mock, and things worked as expected! Best regards, Robin > On 24 May 2019, at 23:33, Igor Ignatyev wrote: > > @Erik, Thanks! > > @hotspot (looking at Robin), can I get another

RFR: JDK-8218807: Compilation database (compile_commands.json) may contain obsolete items

Hi all, When generating a compilation database by either "make compile-commands" or "make compile-commands-hotspot", every object file that should be built results in a temporary json fragment describing the compiler invocation. However, when the final compile_commands.json file is assembled,

Re: Is there a cmakelists.txt file of openjdk11

(moving to build-dev) Hi, As of version 2018.2 [1], as an alternative to CMakeLists.txt, CLion can make use of compile_commands.json [2] as well. After configuring your build, you can generate such a file with the JDK make system: $ make compile-commands Or alternatively, if you are only

Re: RFR: 8212004: Optional compile_commands.json field not compatible with older libclang

Hi Erik, Thanks for reviewing! Best regards, Robin > On 10 Oct 2018, at 17:34, Erik Joelsson wrote: > > Looks good. > > /Erik > > > On 2018-10-10 07:02, Robin Westberg wrote: >> Hi all, >> >> Please review this small change to remove the “output

RFR: 8212004: Optional compile_commands.json field not compatible with older libclang

Hi all, Please review this small change to remove the “output” field from the compile_commands.json file generated by “make compile-commands”. As it turns out, this optional field is incompatible with tooling built on libclang versions older than 4.0. As this field provides no real benefit for

Re: RFR: 8210459: Add support for generating compile_commands.json

tly speaking so should the awk program lines be in this > case. No need for respin. > > /Erik > > > On 2018-10-04 06:31, Magnus Ihse Bursie wrote: >>> 4 okt. 2018 kl. 15:03 skrev Robin Westberg : >>> >>> Hi Magnus, >>> >>&g

Re: RFR: 8210459: Add support for generating compile_commands.json

dline files from a build >>>> of “make jdk” with and without the patch applied (and with >>>> --with-version-opt= set during configure to avoid the timestamp). The only >>>> difference so far is that the EXTRA_OBJECT_FILES change for the >>>> make/launcher

Re: RFR: 8210459: Add support for generating compile_commands.json

Hi Erik, > On 3 Oct 2018, at 20:51, Erik Joelsson wrote: > > Hello Robin, > > make/CompileCommands.gmk: typo in comment: “prepened" Fixed. (Couldn’t resist a slight rewording so the text has reflowed a bit, sorry!) > On 2018-10-03 11:09, Robin Westberg wrote: >

Re: RFR: 8210459: Add support for generating compile_commands.json

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

Re: RFR: 8210459: Add support for generating compile_commands.json

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

Re: RFR: 8210459: Add support for generating compile_commands.json

k the first one is ok as is? 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

RFR: 8210459: Add support for generating compile_commands.json

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

Re: RFR: 8199619: Building HotSpot on Windows should define NOMINMAX

Thanks Erik! Best regards, Robin > On 28 Mar 2018, at 17:47, Erik Joelsson <erik.joels...@oracle.com> wrote: > > I will sponsor the change. > > /Erik > > > On 2018-03-28 06:43, Robin Westberg wrote: >> Hi Kim, >> >>> On 26 Mar 2018, a

Re: RFR: 8199619: Building HotSpot on Windows should define NOMINMAX

Hi Kim, > On 26 Mar 2018, at 18:34, Kim Barrett <kim.barr...@oracle.com> wrote: > >> On Mar 26, 2018, at 11:01 AM, Robin Westberg <robin.westb...@oracle.com> >> wrote: >> >> Hi all, >> >> Please review this small change that defines t

Re: RFR: 8199736: Define WIN32_LEAN_AND_MEAN before including windows.h

Hi David, Thanks for reviewing! I’ll delay progressing this one a bit until 8199619 is integrated. Best regards, Robin > On 27 Mar 2018, at 02:57, David Holmes <david.hol...@oracle.com> wrote: > > Looks good to me. > > Thanks, > David > > On 27/03/2018 1:01 A

Re: RFR: 8199619: Building HotSpot on Windows should define NOMINMAX

Hi Magnus, Thanks for the review! Best regards, Robin > On 26 Mar 2018, at 23:24, Magnus Ihse Bursie <magnus.ihse.bur...@oracle.com> > wrote: > > On 2018-03-26 17:01, Robin Westberg wrote: >> Hi all, >> >> Please review this small change that defines

Re: RFR: 8199619: Building HotSpot on Windows should define NOMINMAX

Hi Erik, Thanks for reviewing! Best regards, Robin > On 26 Mar 2018, at 17:50, Erik Joelsson <erik.joels...@oracle.com> wrote: > > Looks good. > > /Erik > > > On 2018-03-26 08:01, Robin Westberg wrote: >> Hi all, >> >> Please review this s

RFR: 8199619: Building HotSpot on Windows should define NOMINMAX

Hi all, Please review this small change that defines the NOMINMAX macro when building HotSpot on Windows. Issue: https://bugs.openjdk.java.net/browse/JDK-8199619 Webrev: http://cr.openjdk.java.net/~rwestberg/8199619/webrev.00/ Testing:

Re: RFR: 8199736: Define WIN32_LEAN_AND_MEAN before including windows.h

Hi David, Thanks for taking a look! > On 26 Mar 2018, at 01:03, David Holmes <david.hol...@oracle.com> wrote: > > Hi Robin, > > On 23/03/2018 10:37 PM, Robin Westberg wrote: >> Hi Kim & Erik, >> Certainly makes sense to define it from the build system, I

Re: RFR: 8199736: Define WIN32_LEAN_AND_MEAN before including windows.h

com>: >> >> I think this looks good, but Magnus is currently refactoring the flags >> handling in configure so better get his input as well. (adding build-dev) >> >> /Erik >> >> >>> On 2018-03-23 05:37, Robin Westberg wrote: >>

Re: RFR: 8199736: Define WIN32_LEAN_AND_MEAN before including windows.h

build-dev) > /Erik > > On 2018-03-23 05:37, Robin Westberg wrote: >> Hi Kim & Erik, >> >> Certainly makes sense to define it from the build system, I’ve updated the >> patch accordingly: >> >> Full: http://cr.openjdk.java.net/~rwestberg/8199736/webrev