From martijnverburg at gmail.com Tue Apr 8 07:40:57 2014 From: martijnverburg at gmail.com (Martijn Verburg) Date: Tue, 8 Apr 2014 08:40:57 +0100 Subject: Proposal to update build documentation Message-ID: Hi all, The Adoption Group is about to embark on it's migration of all of its documentation on building OpenJDK (adoptopenjdk.java.net contains a bunch of pages). We found your group page at http://openjdk.java.net/groups/build/and wiki at https://wiki.openjdk.java.net/display/Build/Main and figured our documentation should really fall under your gropup's banner (we can reference it from the Adoption Group for new comers). So our proposal is to: 1.) Compare the docs that we have vs what's contained in the various README-builds.html files 2.) Send in patches to README-builds.html where appropriate 3.) Only document temporary workarounds / known issues etc in the Build group's wiki And the one I was more uncertain about: * Document uncommon build scenarios Build group's wiki, e.g. What certain unusual flags mean and so forth. Does this sound reasonable? I'm happy to walk through the existing documentation set that we have with someone so you have a clear idea on what we're proposing to bring across. Cheers, Martijn From martijnverburg at gmail.com Tue Apr 8 07:44:39 2014 From: martijnverburg at gmail.com (Martijn Verburg) Date: Tue, 8 Apr 2014 08:44:39 +0100 Subject: Suggested changes for Build Group Page (add jdk9 and build-infra links) Message-ID: Hi all, Was just looking at http://openjdk.java.net/groups/build/ and noticed that there's no links for: 1.) jdk9 build docs - http://hg.openjdk.java.net/jdk9/build/raw-file/tip/README-builds.html ? 2.) The build-infra-dev mailing list - (Is build-dev effectively dead/dormant now?) I think there were also some personnel reshuffling. Cheers, Martijn From erik.joelsson at oracle.com Tue Apr 8 08:21:26 2014 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Tue, 08 Apr 2014 10:21:26 +0200 Subject: Proposal to update build documentation In-Reply-To: References: Message-ID: <5343B186.7090906@oracle.com> Build documentation is certainly in need of a lot of love. I'm sure Magnus will have something to add to this, but from me I very much welcome this initiative. /Erik On 2014-04-08 09:40, Martijn Verburg wrote: > Hi all, > > The Adoption Group is about to embark on it's migration of all of its > documentation on building OpenJDK (adoptopenjdk.java.net contains a bunch > of pages). We found your group page at > http://openjdk.java.net/groups/build/and wiki at > https://wiki.openjdk.java.net/display/Build/Main and figured our > documentation should really fall under your gropup's banner (we can > reference it from the Adoption Group for new comers). > > So our proposal is to: > > 1.) Compare the docs that we have vs what's contained in the various > README-builds.html files > 2.) Send in patches to README-builds.html where appropriate > 3.) Only document temporary workarounds / known issues etc in the Build > group's wiki > > And the one I was more uncertain about: > > * Document uncommon build scenarios Build group's wiki, e.g. What certain > unusual flags mean and so forth. > > Does this sound reasonable? I'm happy to walk through the existing > documentation set that we have with someone so you have a clear idea on > what we're proposing to bring across. > > Cheers, > Martijn From kmcguigan at twitter.com Wed Apr 16 21:13:01 2014 From: kmcguigan at twitter.com (Keith McGuigan) Date: Wed, 16 Apr 2014 17:13:01 -0400 Subject: JDK-8025705 Message-ID: Hello, I just added a comment to this bug -- see there for the details, but in short I'd like to update a number of tests in the makefiles that check OPENJDK and change them to check instead of the inverse definition of some new variable, such as ORACLEJDK. This would simply non-OpenJDK (i.e., src/closed builds), non-Oracle builds for those who are making their own distributions using the src/closed mechanism. As you can guess, that is something we are doing here at Twitter :) If I were to put together a patch that does this, could someone work with me in getting it integrated into jdk9? Also, what is the process to backport it to the jdk8u repositories? -- - Keith From david.holmes at oracle.com Thu Apr 17 01:15:07 2014 From: david.holmes at oracle.com (David Holmes) Date: Thu, 17 Apr 2014 11:15:07 +1000 Subject: JDK-8025705 In-Reply-To: References: Message-ID: <534F2B1B.9080904@oracle.com> Hi Keith, On 17/04/2014 7:13 AM, Keith McGuigan wrote: > Hello, > > I just added a comment to this bug -- see there for the details, but in > short I'd like to update a number of tests in the makefiles that check > OPENJDK and change them to check instead of the inverse definition of some > new variable, such as ORACLEJDK. Please no! It's bad enough this is implicitly in the build without making it explicit! Would file existence tests suffice? There should be a CUSTOM_SRC variable for src/closed as there is CUSTOM_MAKE for make/closed. > This would simply non-OpenJDK (i.e., > src/closed builds), non-Oracle builds for those who are making their own > distributions using the src/closed mechanism. As you can guess, that is > something we are doing here at Twitter :) Hopefully you use src/custom (or whatever) not src/closed, as otherwise there's no way to tell the difference between our custom sources and yours. David ----- > If I were to put together a patch that does this, could someone work with > me in getting it integrated into jdk9? Also, what is the process to > backport it to the jdk8u repositories? > > -- > - Keith > From kmcguigan at twitter.com Thu Apr 17 03:31:50 2014 From: kmcguigan at twitter.com (Keith McGuigan) Date: Wed, 16 Apr 2014 23:31:50 -0400 Subject: JDK-8025705 In-Reply-To: <534F2B1B.9080904@oracle.com> References: <534F2B1B.9080904@oracle.com> Message-ID: On Wed, Apr 16, 2014 at 9:15 PM, David Holmes wrote: > Hi Keith, > > > On 17/04/2014 7:13 AM, Keith McGuigan wrote: > >> Hello, >> >> I just added a comment to this bug -- see there for the details, but in >> short I'd like to update a number of tests in the makefiles that check >> OPENJDK and change them to check instead of the inverse definition of some >> new variable, such as ORACLEJDK. >> > > Please no! It's bad enough this is implicitly in the build without making > it explicit! > As I mentioned, I agree that moving all this to closed makefiles is the best solution (and is something that we could push for even if we took this partial step), but doing at least this step would be a vast improvement from our point of view and is much easier to implement, especially for someone like me who cannot do the make/closed refactoring. > Would file existence tests suffice? There should be a CUSTOM_SRC variable > for src/closed as there is CUSTOM_MAKE for make/closed. It's not really feasible for the jdk makefiles. Almost each location where there is an OPENJDK test, when it is discovered that this isn't OpenJDK, it ends up referring to files in src/closed (which for us don't exist). In Hotspot it's only a few makefiles, so not too bad there, but jdk is a different story. But really, there's three situations here, OpenJDK, OracleJDK, and OtherJDK/custom, which can't be encoded using one boolean makefile variable. We really need at least one more here. Why is ORACLEJDK so abhorent? This would simply non-OpenJDK (i.e., >> src/closed builds), non-Oracle builds for those who are making their own >> distributions using the src/closed mechanism. As you can guess, that is >> something we are doing here at Twitter :) >> > > Hopefully you use src/custom (or whatever) not src/closed, as otherwise > there's no way to tell the difference between our custom sources and yours. > The makefiles are already setup to use src/closed, so really that's the most convenient way to add augmented sources to the build. We'd very much like to avoid changing mainline code to reduce the maintenance/merge costs when things change. I'm not sure it would help even if we did use a custom directory instead of 'closed' though -- unless we went ahead and duplicated all of the 'closed' logic for 'custom' (which again, would incur maintenance costs and is not generally good engineering practice). -- - Keith From david.holmes at oracle.com Thu Apr 17 04:52:53 2014 From: david.holmes at oracle.com (David Holmes) Date: Thu, 17 Apr 2014 14:52:53 +1000 Subject: JDK-8025705 In-Reply-To: References: <534F2B1B.9080904@oracle.com> Message-ID: <534F5E25.8060408@oracle.com> Hi Keith, 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 problem. That would be a first step in moving things to the custom makefiles where they belong. I'm opposed to the ORACLEJDK variable because I want to maintain the pressure to get this fixed properly. If we hack around it then it will never get cleaned up. I see 68 uses of src/closed across 14 files in the JDK repo. That seems tractable. I think there are three things to be done here: 1. Replace all uses of src/closed with CUSTOM_SRC_DIR (similar to CUSTOM_MAKE_DIR) which in turn is set via configure 2. Guard all uses of CUSTOM_SRC_DIR in open makefiles with an existence check 3. Move all uses of CUSTOM_SRC_DIR to our closed makefiles Steps 1 and 2 can happen now. Step 3 is long term goal. --- The other problem I see with the OPENJDK, ORACLE_JDK, OTHER_JDK approach is that you actually have to deal with the permutations. Something currently flagged for OPENJDK really means !ORACLE_JDK - or does it? It actually depends on what sources a given licensee has. Even for your custom build you might want some OPENJDK items and not others. I'm not sure there is a general solution, but using OPENJDK in combination with CUSTOM_SRC_DIR is, I think, more flexible than trying to define discrete variables that represent build "targets". David On 17/04/2014 1:31 PM, Keith McGuigan wrote: > On Wed, Apr 16, 2014 at 9:15 PM, David Holmes > wrote: > > Hi Keith, > > > On 17/04/2014 7:13 AM, Keith McGuigan wrote: > > Hello, > > I just added a comment to this bug -- see there for the details, > but in > short I'd like to update a number of tests in the makefiles that > check > OPENJDK and change them to check instead of the inverse > definition of some > new variable, such as ORACLEJDK. > > > Please no! It's bad enough this is implicitly in the build without > making it explicit! > > > As I mentioned, I agree that moving all this to closed makefiles is the > best solution (and is something that we could push for even if we took > this partial step), but doing at least this step would be a vast > improvement from our point of view and is much easier to implement, > especially for someone like me who cannot do the make/closed refactoring. > > Would file existence tests suffice? There should be a CUSTOM_SRC > variable for src/closed as there is CUSTOM_MAKE for make/closed. > > > It's not really feasible for the jdk makefiles. Almost each location > where there is an OPENJDK test, when it is discovered that this isn't > OpenJDK, it ends up referring to files in src/closed (which for us don't > exist). In Hotspot it's only a few makefiles, so not too bad there, but > jdk is a different story. > > But really, there's three situations here, OpenJDK, OracleJDK, and > OtherJDK/custom, which can't be encoded using one boolean makefile > variable. We really need at least one more here. Why is ORACLEJDK so > abhorent? > > This would simply non-OpenJDK (i.e., > src/closed builds), non-Oracle builds for those who are making > their own > distributions using the src/closed mechanism. As you can guess, > that is > something we are doing here at Twitter :) > > > Hopefully you use src/custom (or whatever) not src/closed, as > otherwise there's no way to tell the difference between our custom > sources and yours. > > > The makefiles are already setup to use src/closed, so really that's the > most convenient way to add augmented sources to the build. We'd very > much like to avoid changing mainline code to reduce the > maintenance/merge costs when things change. I'm not sure it would help > even if we did use a custom directory instead of 'closed' though -- > unless we went ahead and duplicated all of the 'closed' logic for > 'custom' (which again, would incur maintenance costs and is not > generally good engineering practice). > > -- > - Keith