Re: RFR: 8257733: Move module-specific data from make to respective module

2020/12/4 6:08:13 -0800, er...@openjdk.java.net: > On Fri, 4 Dec 2020 12:30:02 GMT, Alan Bateman wrote: >>> And I can certainly move jdwp.spec to java.base instead. That's the >>> reason I need input on this: All I know is that is definitely not >>> the responsibility of the Build Group to

Re: 15 RFR (XXS) 8250216: The README need not mention retrieving source code

2020/7/23 10:33:34 -0700, iris.cl...@oracle.com: >> Bug: https://bugs.openjdk.java.net/browse/JDK-8250216 >> >> [ ... ] >> >> Patch below. > > Looks good. > > I think it would be nice if you could reference the JDK Project page > (ojn/projects/jdk), not just ojn. Good idea ... but I just

15 RFR (XXS) 8250216: The README need not mention retrieving source code

Bug: https://bugs.openjdk.java.net/browse/JDK-8250216 The README at the root of the source tree says, “For information about building the JDK, including how to retrieve all of the source code, please see ...” yet we haven’t needed instructions on how to retrieve the rest of the source code since

Re: 14 RFR (M) 8232080: jlink plugins for vendor information and run-time options

2019/10/23 12:37:56 -0700, bob.vande...@oracle.com: >> On Oct 23, 2019, at 3:07 PM, mark.reinh...@oracle.com wrote: >> ... >> >> Addendum: To keep things sane for JFR and the serviceability agent, >> I had to propagate this change through to those subsystems. >> >> Relative patch below; original

Re: 14 RFR (M) 8232080: jlink plugins for vendor information and run-time options

2019/10/22 15:36:28 -0700, mark.reinh...@oracle.com: > 2019/10/22 12:43:42 -0700, bob.vande...@oracle.com: >>> On Oct 22, 2019, at 3:22 PM, mark.reinh...@oracle.com wrote: >>> 2019/10/22 10:31:55 -0700, bob.vande...@oracle.com: In arguments.cpp, could you use a new JVMFlag to declare options

Re: 14 RFR (M) 8232080: jlink plugins for vendor information and run-time options

2019/10/22 12:43:42 -0700, bob.vande...@oracle.com: >> On Oct 22, 2019, at 3:22 PM, mark.reinh...@oracle.com wrote: >> 2019/10/22 10:31:55 -0700, bob.vande...@oracle.com: >>> In arguments.cpp, could you use a new JVMFlag to declare options >>> that came from this resource as RESOURCE? >>> >>> -

Re: 14 RFR (M) 8232080: jlink plugins for vendor information and run-time options

2019/10/22 14:12:18 -0700, mandy.ch...@oracle.com: > On 10/21/19 8:22 PM, mark.reinh...@oracle.com wrote: >> RFE: https://bugs.openjdk.java.net/browse/JDK-8232080 >> CSR: https://bugs.openjdk.java.net/browse/JDK-8232753 >> Webrev: https://cr.openjdk.java.net/~mr/rev/8232080/ > > Looks good to me.

Re: 14 RFR (M) 8232080: jlink plugins for vendor information and run-time options

2019/10/22 7:15:10 -0700, alan.bate...@oracle.com: > On 22/10/2019 04:22, mark.reinh...@oracle.com wrote: >> RFE: https://bugs.openjdk.java.net/browse/JDK-8232080 >> CSR: https://bugs.openjdk.java.net/browse/JDK-8232753 >> Webrev: https://cr.openjdk.java.net/~mr/rev/8232080/ > > I've read through

Re: 14 RFR (M) 8232080: jlink plugins for vendor information and run-time options

2019/10/22 10:31:55 -0700, bob.vande...@oracle.com: > In arguments.cpp, could you use a new JVMFlag to declare options that came > from this resource as RESOURCE? > > - jint result = parse_each_vm_init_arg(vm_options_args, _mod_javabase, > JVMFlag::INTERNAL); > + jint result =

14 RFR (M) 8232080: jlink plugins for vendor information and run-time options

RFE: https://bugs.openjdk.java.net/browse/JDK-8232080 CSR: https://bugs.openjdk.java.net/browse/JDK-8232753 Webrev: https://cr.openjdk.java.net/~mr/rev/8232080/ This change implements jlink plugins, and associated changes in the VM and libraries, to support the following new jlink options: -

Re: RFC: JEP JDK-8208089: Implement C++14 Language Features

2018/10/3 12:13:15 -0700, kim.barr...@oracle.com: > ... > > https://bugs.openjdk.java.net/browse/JDK-8208089 Or, more readably: https://openjdk.java.net/jeps/8208089 - Mark

Re: RFR 8208183: update HSDIS plugin license to UPL

2018/8/21 7:25:58 -0700, volker.simo...@gmail.com: > On Tue, Aug 21, 2018 at 12:14 PM, magnus.ihse.bur...@oracle.com wrote: >> ... >> >> I can easily add a new make target to build hsdis. >> >> Adding a new binary to the OpenJDK images will require a CSR. > > Do we really need a CSR for hsdis?

Re: RFR 8208183: update HSDIS plugin license to UPL

2018/8/21 11:11:00 -0700, john.r.r...@oracle.com: > On Aug 21, 2018, at 9:41 AM, Andrew Haley wrote: >> On 08/21/2018 11:14 AM, Magnus Ihse Bursie wrote: >>> Am I correct in understanding that there are no more legal barriers >>> towards doing such a thing anymore? >> >> You'd still be linking

Re: 11 RFR (XS) 8205956: Fix usage of “OpenJDK” in build and test instructions

2018/6/29 3:03:09 -0700, volker.simo...@gmail.com: > This still doesn't explain why replacing one trademark with another > one is helpful here. Perhaps some trademarks are more important than others. > After Phil's remark, OpenJDK doesn't even seem to be registered as a > trademark, so in that

Re: 11 RFR (XS) 8205956: Fix usage of “OpenJDK” in build and test instructions

2018/6/27 23:21:34 -0700, volker.simo...@gmail.com: > On Thu, Jun 28, 2018 at 12:08 AM, mark.reinh...@oracle.com wrote: >> ... >> >> “OpenJDK” is a trademarked term, per the OpenJDK Trademark Notice [1]. >> As such it should be used only as an adjective, and not as a noun. >> Phrases such as “the

Re: 11 RFR (XS) 8205956: Fix usage of “OpenJDK” in build and test instructions

2018/6/28 0:14:26 -0700, Aleksey Shipilev : > On 06/28/2018 08:21 AM, Volker Simonis wrote: >> Sorry, but I don't see any sense in this change! > > +1 > > Also, "(open-source) JDK" is way too generic, and does awkwardly apply > to other JDK's in the wild, including IBM's, Azul's, Excelsior's, >

Re: 11 RFR (XS) 8205956: Fix usage of “OpenJDK” in build and test instructions

2018/6/27 16:19:58 -0700, tim.b...@oracle.com: > Looks good to me as well. > > Tim > > On 06/27/18 15:33, Erik Joelsson wrote: >> Looks good. >> >> /Erik Thanks! - Mark

11 RFR (XS) 8205956: Fix usage of “OpenJDK” in build and test instructions

Bug: https://bugs.openjdk.java.net/browse/JDK-8205956 Webrev: http://cr.openjdk.java.net/~mr/rev/8205956/ Quick links to handier HTML diffs: http://cr.openjdk.java.net/~mr/rev/8205956/doc/building.html.hdiff.html http://cr.openjdk.java.net/~mr/rev/8205956/doc/testing.html.hdiff.html

Re: License and Usage Terms of generated API documentation

2018/5/3 13:16:11 +0100, volker.simo...@gmail.com: > On Thu, May 3, 2018 at 12:21 PM, magnus.ihse.bur...@oracle.com wrote: >> ... >> >> Until a consensus of a better solution for hosting the generated >> documentation is reached, I'd like to avoid changing the build code. That >> will just open

Re: 10 RFR (XS) 8193764: Cannot set COMPANY_NAME when configuring a build

2017/12/18 20:40:19 -0800, Martin Buchholz : > On Mon, Dec 18, 2017 at 3:50 PM, mark.reinh...@oracle.com wrote: >> I didn't know you'd requested this -- is there an existing issue? > > https://bugs.openjdk.java.net/browse/JDK-8189761 Thanks. I cross-linked that with

Re: 10 RFR (XS) 8193764: Cannot set COMPANY_NAME when configuring a build

2017/12/18 15:36:03 -0800, Martin Buchholz : > Mark, thanks for implementing my little feature request. Looks good to me. I didn't know you'd requested this -- is there an existing issue? - Mark

10 RFR (XS) 8193764: Cannot set COMPANY_NAME when configuring a build

Bug: https://bugs.openjdk.java.net/browse/JDK-8193764 Webrev: http://cr.openjdk.java.net/~mr/rev/8193764/ You can set COMPANY_NAME in make/autoconf/version-numbers, but you can't set it when configuring a build, so it's impossible to change the value of IMPLEMENTOR in the $JAVA_HOME/release file

Re: Initial JDK 11 RFR of JDK-8173382: Add -source 11 and -target 11 to javac - Java Bug System & JDK-8193291: Add SourceVersion.RELEASE_11

2017/12/13 15:49:53 -0800, paul.san...@oracle.com: > On 13 Dec 2017, at 14:36, mark.reinh...@oracle.com wrote: >> I understand that other incoming changes are waiting for the 11 version >> bump, but can't we at least do the straightforward parameterizations and >> introduce _CURRENT constants in

Re: Initial JDK 11 RFR of JDK-8173382: Add -source 11 and -target 11 to javac - Java Bug System & JDK-8193291: Add SourceVersion.RELEASE_11

2017/12/13 14:09:44 -0800, paul.san...@oracle.com: >> On 13 Dec 2017, at 13:18, mark.reinh...@oracle.com wrote: >> How much of this can we parameterize and/or automate? > > I suspect quite a bit, as you present below, and i agree we should try > and automate as much as possible. At the moment

Re: Initial JDK 11 RFR of JDK-8173382: Add -source 11 and -target 11 to javac - Java Bug System & JDK-8193291: Add SourceVersion.RELEASE_11

2017/12/13 8:44:33 -0800, paul.san...@oracle.com: >> On 12 Dec 2017, at 20:56, david.hol...@oracle.com wrote: >> >> Anyway, none of the proposed changes have any impact on hotspot >> AFAICT. It is only when the actual version is updated to 11 that >> hotspot, and other entities will have to be

Re: RFR(XXS): 8189919: Update link to license in Docs.gmk

2017/10/26 9:11:08 -0700, iris.cl...@oracle.com: > Please review this small change to update the link to the > > Specification license referenced by the JavaDoc API. For > > JDK 10, we should reference the 10 redirect. > > Bug: > > > > 8189919: Update link to license in Docs.gmk > >

Re: RFR 8182776/8183161/8183251: Miscellaneous API doc fixes

2017/6/30 16:08:09 -0700, jonathan.gibb...@oracle.com: > Mark, > > The font-family settings in the nodes were deliberate, and a > workaround for not having time to create a proper taglet for tool guides. > > If you remove the style attribute, you'll see in your sample output that > the "Tool

RFR 8182776/8183161/8183251: Miscellaneous API doc fixes

8182776: Fix typo "upgradeble" in the javadoc of upgradeable modules 8183161: Remove extraneous font-family style attributes from module declarations 8183251: Meta "keywords" tag malformed in overview-summary.html and related pages http://cr.openjdk.java.net/~mr/rev/8182776/jdk9-dev.patch

Re: RFR 8167227: Simplify the JDK 9 API-specification overview page (docs only)

2017/6/19 10:41:09 +0200, erik.joels...@oracle.com: > Looks good to me. > > The change to the log message is a bit weird. Was this meant as a > temporary way for finding the output file? Good catch -- yes, that was temporary. I'll remove it. Thanks, - Mark

RFR 8167227: Simplify the JDK 9 API-specification overview page (docs only)

http://cr.openjdk.java.net/~mr/rev/8182408/ https://bugs.openjdk.java.net/browse/JDK-8182408 This is a follow-on to Magnus's changes for 8175824. Oracle's legal department has recently advised that the liberal use of trademark symbols on the API-specification overview page is not required. We

Re: RFR: JDK-8172312 Update docs target and image for new combined docs

2017/4/4 12:28:18 -0700, jonathan.gibb...@oracle.com: > Don't we need the JEP to be moved from "Proposed To Target" to > "Targetted" before we can push? Yep. Coming right up ... - Mark

Re: [aarch64-port-dev ] Review Request JDK-8175819: OS name and arch in JMOD files should match the values as in the bundle name

2017/4/4 8:22:50 -0700, a...@redhat.com: > On 04/04/17 16:12, mark.reinh...@oracle.com wrote: >> The trouble here is that "arm64" and "aarch64" are effectively synonyms >> for the ISA, but in the JDK we've wound up using them as the names of >> two different ports. >> >> A JMOD file built for the

Re: RFR: JDK-8172312 Update docs target and image for new combined docs

2017/4/4 4:47:58 -0700, magnus.ihse.bur...@oracle.com: > Here is an updated webrev: > http://cr.openjdk.java.net/~ihse/JDK-8172312-combined-javadocs/webrev.03 > > The only change compared to the previous webrev is that I have updated > the title for the JDK javadocs so it does not claim to be

Re: Review Request JDK-8175819: OS name and arch in JMOD files should match the values as in the bundle name

2017/4/4 1:04:22 -0700, magnus.ihse.bur...@oracle.com: > On 2017-04-03 23:50, Mandy Chung wrote: >> ... >> >>JDK 8 JDK 9 >>- - >> OS_NAMELinux linux >>SunOS solaris >>Darwin

Re: RFR: JDK-8172312 Update docs target and image for new combined docs

2017/4/3 11:01:13 -0700, jonathan.gibb...@oracle.com: > I agree there will need to be some cosmetic cleanup with respect to > headings. Given the optionality of whether or not the build is set to > import JavaFX, the headings and content of the new overview page will > need to be somewhat

Re: RFR: JDK-8172312 Update docs target and image for new combined docs

2017/4/3 3:24:52 -0700, magnus.ihse.bur...@oracle.com: > I think the distinction you ask for is already there. The two separate > make targets "docs-javadoc" and "docs-reference" builds two distinct > images "docs" and "javase-docs", respectively. The first of these builds > the complete Java

Re: Review Request JDK-8175819: OS name and arch in JMOD files should match the values as in the bundle name

2017/4/3 14:50:52 -0700, mandy.ch...@oracle.com: >> On Apr 3, 2017, at 2:39 PM, mark.reinh...@oracle.com wrote: >> 2017/4/3 13:35:30 -0700, si...@cjnash.com: >>> ... >>> >>> I am not sure why we would change to osx for Mac when the Mac developers >>> have recently dropped the Mac OS X terminology

Re: Review Request JDK-8175819: OS name and arch in JMOD files should match the values as in the bundle name

2017/4/3 13:35:30 -0700, si...@cjnash.com: > On 03/04/2017 21:15, mark.reinh...@oracle.com wrote: >> 2017/4/3 11:41:03 -0700, mandy.ch...@oracle.com: >>> Webrev: >>> http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8175819/webrev.00/ >>> >>> ... >>> >>> This shows the old and new value of

Re: Review Request JDK-8175819: OS name and arch in JMOD files should match the values as in the bundle name

2017/4/3 11:41:03 -0700, mandy.ch...@oracle.com: > Webrev: > http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8175819/webrev.00/ > > ... > > This shows the old and new value of OS_NAME/OS_ARCH properties > in the `release` file: > > JDK 8 JDK 9 > -

Re: RFR: JDK-8172312 Update docs target and image for new combined docs

2017/3/30 6:05:43 -0700, magnus.ihse.bur...@oracle.com: > As a part of JEP 299, we should build the Javadoc as a single combined > output, instead of a dozen or so individual javadoc bundles. This bug > fixes this. The selection on what to include is now based on modules > instead of packages.

Re: New lead for the JDK 6 Project: Andrew Brygin

2017/1/6 7:30:28 -0800, tim.b...@oracle.com: > Andrew Haley has resigned as lead for the JDK 6 Project [1]. > > Under the bylaws for Project Roles [2], a new Project Lead may be > nominated by the Group Leads of the Project's sponsoring groups. > > The Build Infrastructure Group is sponsor of

Re: JDK 9 RFR of JDK-8072480: javac should support compilation for a specific platform version

2015/5/21 12:01 -0700, jan.lah...@oracle.com: This is a patch adding a new option, -platform, to javac. Patch for the top-level repository is here: http://cr.openjdk.java.net/~jlahoda/8072480/webrev.00/top-level/ Patch for the langtools repository is here:

Re: OpenJDK Governing Board CFV: New Build Group Lead: Tim Bell

2015/1/20 9:28 -0800, mark.reinh...@oracle.com: Kelly O'Hair resigned as the Lead of the Build Group in April 2014 [1]. Tim Bell was voted in as the new Group Lead shortly thereafter [2]. (Unfortunately this particular change slipped through the cracks, which is why you're only hearing about

Re: Adding Microbenchmarks to the JDK forest/trees (JEP-230)

2014/12/4 9:51 -0800, staffan.frib...@oracle.com: On 12/03/2014 02:58 AM, Magnus Ihse Bursie wrote: ... My suggestion is that the microbenchmarks are put in the top-level repo, if only for the reason that it seems fully possible to split them out to a separate repo some time in the future

Re: Adding Microbenchmarks to the JDK forest/trees (JEP-230)

2014/12/1 4:08 -0800, staffan.frib...@oracle.com: Hopefully this is the right list for this discussion. This change is going to affect many more people than just those interested in the build. Suggest you float this on jdk9-dev. - Mark

Re: JDK-8025705

2014/4/22 21:23 -0700, kmcgui...@twitter.com: Yes, I did consider using some ifeq tricks like that -- but they are rather ugly and unreadable and have the same problem that you want to avoid: adding distribution-specific code into the open-source makefiles. My goal here is to have the public

Re: JDK-8025705

2014/4/16 14:52 -0700, david.hol...@oracle.com: src/closed is Oracle's custom source location (hotspot calls it alt_src). If we never saw src/closed in the makefiles, only CUSTOM_SRC_DIR, and guarded with an existence test for a specific directory/file, then that should address your

Re: Code review request: 8031372 JDK 9 Specification-Version in jar files is still 1.8

2014/1/8 16:47 -0800, erik.joels...@oracle.com: ... For the future, is there a reason for not automatically generating the specification-version based on the version numbers we have, or at least move the definition of it to the version numbers file? Excellent question. We should try to

Re: J2SE est mort, vive Java SE!

2013/11/26 8:29 -0800, david.hol...@oracle.com: On 27/11/2013 8:49 AM, mark.reinh...@oracle.com wrote: Now that we've removed the old build system, can we please now remove the last vestiges of Sun's pre-Java 5 naming scheme? There are also a bunch of security libs with j2 in their names -

Re: J2SE est mort, vive Java SE!

2013/11/26 23:33 -0800, sean.mul...@oracle.com: On 11/27/2013 03:41 AM, Alan Bateman wrote: The security providers have vestiges of Sun in the provider names (SUN, SunPKCS11, SunJSSE ..) but these are documented and I don't think can be changed (although it not recommended to select services

J2SE est mort, vive Java SE!

Now that we've removed the old build system, can we please now remove the last vestiges of Sun's pre-Java 5 naming scheme? I refer in particular to these directories in a typical build: images/j2re-image images/j2sdk-image images/j2sdk-server-image The j2 nomenclature hasn't been used

Re: Le roi est mort, vive le roi!

2013/11/18 2:02 -0800, magnus.ihse.bur...@oracle.com: So, finally it has happened. The old build system is now removed. ... Huzzah! - Mark

Re: Removal of the old build system, partial review

2013/10/31 2:41 -0700, kellyoh...@gmail.com: With build logic, it is relatively easy to build before and after and verify the exact same resulting bits. So the risk is considerably less than in other areas of software development. There might be more risk leaving it in, where the wrong

INFO: ENABLE_FULL_DEBUG_SYMBOLS=1, etc., in build log

The following lines are repeated over and over when building JDK 8: INFO: ENABLE_FULL_DEBUG_SYMBOLS=1 INFO: ALT_OBJCOPY=/usr/bin/objcopy INFO: /usr/bin/objcopy cmd found so will create .debuginfo files. INFO: STRIP_POLICY=min_strip INFO: ZIP_DEBUGINFO_FILES=1 It seems like a lot of

Re: INFO: ENABLE_FULL_DEBUG_SYMBOLS=1, etc., in build log

2013/6/5 10:22 -0700, david.hol...@oracle.com: This comes from hotspot build. The FDS processing happens in a file that is included a number of times due to the nested make invocations that happen with hotspot. Consequently this gets repeated a few times (actually fewer than it used to) for

Re: Windows configure issues

2013/5/21 6:54 -0700, gnu.and...@redhat.com: On 05/21/2013 04:55 PM, Volker Simonis wrote: I always felt that having the build instructions checked in into the repository is somewhat to heavyweight. There are two good reasons to do this. Firstly, it's a free software tradition: I expect

Preserving changeset authorship (was Re: PING: [PATCH] Enable debug info on all libraries for OpenJDK builds)

2013/5/9 2:10 -0700, gnu.and...@redhat.com: Indeed. I do this with the Oracle patches when applying them to IcedTea. The problem is how this gets done is down to the sponsor; I've had ones that have been imported, ones where I've just been giving the Contributed-by attribution (despite having

Re: Preserving changeset authorship (was Re: PING: [PATCH] Enable debug info on all libraries for OpenJDK builds)

2013/5/9 8:14 -0700, philip.r...@oracle.com: (Yes, this is one of those rare cases in which a sponsor should use the -u option.) I'd hazard a guess that there are number of people who overlook this option in part because they don't realise you can do hg commit -u SOMEBODY-ELSE ... I

Re: Request for review: 8009529: Fix for 8006988 missed closed configure changes

2013/3/5 11:39 -0800, david.hol...@oracle.com: We need to regenerate the open and closed configure scripts in the tl forest. The open change is trivial as it just updates the timestamp: hg diff diff -r c4901c0e0579 common/autoconf/generated-configure.sh ---

Re: invalid bug IDs aborting my pull

2012/11/14 8:17 -0800, peter.bru...@oracle.com: I looked in jcheck.py and see: if not (bs[0] in ['1','2','4','5','6','7']): ch.error(ctx, Invalid bugid: %s % bs) so either I don't have the latest or '8' needs to be added. I'll try that. You have an antique copy of jcheck. Get a

Re: [8] Review request for 8000693 Move jdk.tbom from jdk/make/closed to jdk repository

2012/10/10 16:21 -0700, michael.f...@oracle.com: This was originally submitted as 7196354 check-in jdk.tbom file to openjdk repo, but the file was checked in to the closedjdk repository. The automated translation drop system handles penjdk and closedjdk resource files separately as 2

Re: [8] Review request for 7196354 check-in jdk.tbom file to openjdk repo

2012/9/10 14:26 -0700, michael.f...@oracle.com: I have updated the webrev: http://cr.openjdk.java.net/~mfang/7196354/webrev.01/ ... I am also moving the file from root of source tree to jdk/make/jdk.tbom. SGT strongly recommends we follow the standard file naming convention used by the

Re: [8] Review request for 7196354 check-in jdk.tbom file to openjdk repo

2012/9/5 14:08 -0700, michael.f...@oracle.com: Please help to review the new JDK8 file for the following CR: 7196354 check-in jdk.tbom file to openjdk repo The webrev is located at: http://cr.openjdk.java.net/~mfang/7196354/webrev.00/ This file needs a more descriptive name, especially if

Re: Any plan to cleanup x86 arch names?

2012/8/15 4:52 -0700, magnus.ihse.bur...@oracle.com: Unfortunately, it is not that simple to just replace everything with x86. Sad, but true. ... 2) Changing names on files or directories (unfortunately) makes version control harder. If files are to be moved around all over the place

hg: jdk8/build/jdk: 7110396: Sound code fails to build with gcc 4.6 on multiarch Linux systems

Changeset: d3b334e376d3 Author:mr Date: 2012-01-23 12:39 -0800 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/d3b334e376d3 7110396: Sound code fails to build with gcc 4.6 on multiarch Linux systems Reviewed-by: ohair ! make/javax/sound/jsoundalsa/Makefile

Re: Build openjdk in Ubuntu 11.10

2012/1/13 9:33 -0800, michael.j.silvers...@gmail.com: I am getting the following error when building openjdk 7.0 on ubuntu 11.10 But I already have the package libasound2-dev installed. This is 7110396. You need this patch: diff --git a/make/javax/sound/jsoundalsa/Makefile

Re: Review request (XS): 7110396: Sound code fails to build on multiarch Linux systems

2011/11/10 4:49 -0800, robert.otten...@oracle.com: The patch is correct, but in order to follow the convention in most other makefiles, I advice to use OTHER_LDLIBS instead of EXTRA_LIBS. Ah, thanks. I missed that one when reading through the common makefiles. 2011/11/10 5:16 -0800,

Re: Review request (XS): 7110396: Sound code fails to build on multiarch Linux systems

2011/11/10 17:45 -0800, david.hol...@oracle.com: On 11/11/2011 1:47 AM, mark.reinh...@oracle.com wrote: 2011/11/10 4:49 -0800, robert.otten...@oracle.com: The patch is correct, but in order to follow the convention in most other makefiles, I advice to use OTHER_LDLIBS instead of EXTRA_LIBS.

Review request (XS): 7110396: Sound code fails to build on multiarch Linux systems

Some Linux distros have started to adopt a multiarch filesystem layout for shared libraries in order to support the installation of packages for multiple hardware architectures on a single system. For more information see, e.g., http://wiki.debian.org/Multiarch. In Ubuntu 11.10 the ALSA shared

Re: Should the Build Group sponsor the JDK 7 Update project?

Vote: yes - Mark

Re: Build Group Membership vote

2011/5/11 10:20 -0700, kelly.oh...@oracle.com: Should the following person be added as a member of the OpenJDK Build Group? David Katleman http://db.openjdk.java.net/people/katleman Vote: yes - Mark

Re: Build Group Membership vote

2011/5/11 10:55 -0700, kelly.oh...@oracle.com: Should the following person be added as a member of the OpenJDK Build Group? Phil Race http://db.openjdk.java.net/people/prr Vote: yes - Mark

Re: Should the Build Group sponsor the Build Infrastructure Project?

2011/5/11 8:23 -0700, kelly.oh...@oracle.com: Should the Build Group sponsor the Build Infrastructure Project [1]? Vote: yes - Mark

Re: demo vs. sample directories in the jdk

2011/3/16 7:55 -0700, alan.bate...@oracle.com: ... Today we have a sample and a demo directory and it's not always clear where to put new sample code. I'm trying to remember why we have two locations. I think, but might be wrong, that the demo directory is sample code

Re: Need reviewer

Okay, I can live with this. (At the risk of stating the obvious: Please be sure to use hg mv when you rename these files, otherwise the historical changeset trail will be broken.) - Mark

Re: Need reviewer

Date: Sun, 11 Oct 2009 17:35:31 -0700 From: kelly.oh...@sun.com 6888701: Change all template java source files to a .java.template file suffix http://cr.openjdk.java.net/~ohair/openjdk7/jdk7-build-template-6888701/webrev/ Most of the files you are renaming in this change are in NIO, and

Re: Should GNU make 3.81 be required?

Date: Tue, 15 Sep 2009 10:44:08 -0700 From: joe.da...@sun.com For as long as I remember, we've used make 3.78.*. I assume the most problematic platform to upgrade is windows. However, if there are significant benefits build time benefits, I think upgrading the make version is justified. I

Re: Request for review: Bug 100054: Make building the Nimbus look 'n' feel optional

Date: Thu, 21 May 2009 16:51:24 +0100 From: Andrew John Hughes gnu_and...@member.fsf.org ... Looks like the Contributed-by info is wrong. I tried adding the line as in the example and jcheck choked: remote: Contributed-by: Andrew John Hughes ahughes at redhat.com remote: remote:

Re: Request for review: Bug 100054: Make building the Nimbus look 'n' feel optional

Date: Mon, 18 May 2009 19:17:21 +0100 From: Andrew John Hughes gnu_and...@member.fsf.org Ok, new webrev created against jdk7/build: http://fuseyism.com/6841728/webrev.01/ Looks good to me -- go ahead and push when ready. I presume I need to wait a bit due to the current block on pushes

Re: Request for review: Bug 100054: Make building the Nimbus look 'n' feel optional

Date: Fri, 15 May 2009 16:30:04 +0100 From: Andrew John Hughes gnu_and...@member.fsf.org I was thinking this as I read your mail. It should be easy enough to add this as an #else clause to the existing patch in Sanity.gmk. What's the best way to handle updating the patch, given that the

Re: Request for review: Bug 100054: Make building the Nimbus look 'n' feel optional

Date: Fri, 15 May 2009 09:08:39 -0700 From: jonathan.gibb...@sun.com What is your experience with the combination of mq and jcheck? None, so far, since jcheck is disabled in the Jigsaw forest. I like having jcheck enabled as a preextension hook, but that didn't work well with mq. Hmm,

Re: Swing Dev Request for review: Bug 100054: Make building the Nimbus look 'n' feel optional

Date: Fri, 15 May 2009 20:19:47 +0400 From: peter.zheleznia...@sun.com Mark Reinhold wrote: Date: Fri, 15 May 2009 07:16:01 -0700 From: jonathan.gibb...@sun.com Yeah, tried that, didn't work for me; I had to do real work so I gave up and downloaded and went back to using 0.9.5

Re: Request for review: Bug 100054: Make building the Nimbus look 'n' feel optional

Date: Fri, 15 May 2009 18:32:14 +0100 From: Andrew John Hughes gnu_and...@member.fsf.org 2009/5/15 Mark Reinhold m...@sun.com: One changeset is best.  You need somehow to revert the changeset Somehow I thought that's what you were going to say.. :) Looks like I can do a hg backout

Re: make sanity RFE

Date: Thu, 28 Aug 2008 00:19:24 +0200 From: [EMAIL PROTECTED] sudo apt-get build-dep openjdk-6 should get you the necessary build dependencies installed. Wow. That is just too slick for words. - Mark

Re: hg: jdk7/build/jdk: 2 new changesets

Date: Tue, 10 Jun 2008 18:09:10 -0700 From: Martin Buchholz [EMAIL PROTECTED] I did my last hg push from a Google machine. I have no idea why mercurial notification thinks I am [EMAIL PROTECTED] Because that's the address you entered when you originally registered. I'd like to have control

Re: Mercurial repositories offline?

Date: Tue, 22 Apr 2008 13:22:58 +0200 From: Clemens Eisserer [EMAIL PROTECTED] It looks like the mercurial-servers are down, I only get 500 - Internal Server Error. Is this already known and when can I expect it to be fixed? Exactly what are you trying to do, and with what URL? Everything

Re: Extending the pattern list in .hgignore to exclude webrev directories

Date: Fri, 01 Feb 2008 14:21:07 +0100 From: [EMAIL PROTECTED] I'd like to suggest to extend .hgignore with these two lines: ^webrev/ ^webrev_.*/ It would make it possible to keep several webrevs in your working repository without polluting the output of 'hg status' Well, of course

Re: Quick confirmation

Date: Fri, 25 Jan 2008 03:02:04 -0800 From: [EMAIL PROTECTED] On Jan 25, 2008, at 2:20 AM, Volker Simonis wrote: I've also noticed that there are no updates in the Mercurial repositories since the inital b24 upload. Is this because of the distributed nature of mercurial and the fact that

Re: JDK 7 Project

Vote: yes (duh) - Mark

Tags for promoted builds

Date: Sat, 10 Nov 2007 04:27:39 + From: [EMAIL PROTECTED] Changeset: 2e4d6d562de7 Author:xdono Date: 2007-11-09 20:03 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/rev/2e4d6d562de7 Added tag jdk7-ea-b99 for changeset 8792e7dbf130 The problem with this tag format,

Re: Sparse repositories and fclone/fpull

Date: Mon, 12 Nov 2007 14:58:16 -0800 From: [EMAIL PROTECTED] ... Yep, the subrepository I deleted was recreated...sigh...looks like I have to keep everything around, or else clone each subrepository separately. So, is there an option to only update the subrepositories that are present?

Sandboxes available

I've created a couple of sandbox trees on hg.openjdk.java.net. sandbox/simple is a simple push/pull tree that works in the obvious way. sandbox/box is a gated tree; you pull from sandbox/box, and then push (via ssh) to sandbox/box-gate. If your new changesets pass the gate checks then they'll

Re: Group forests created

Date: Wed, 07 Nov 2007 21:05:43 +0200 From: Frederic Simon [EMAIL PROTECTED] Without hacking hgwebdir.cgi, you can eneter multiple ScriptAlias in apache conf that will point to different hgweb.config files (and each has a different set of repo path). That'd work -- if we were running this

Group forests created

I've created and loaded a set of experimental group integration forests on hg.openjdk.java.net. These are the forests to which individual developers will push their changes. Group integrators are responsible for periodically syncing with the master forest and pushing changes up to the master