Hi David, Most of the problem resides in jdk/make, in the following files: make/CompileDemos.gmk make/CompileJavaClasses.gmk make/CopyFiles.gmk make/CopyIntoClasses.gmk make/CreateSecurityJars.gmk make/gensrc/GensrcIcons.gmk make/Images.gmk make/lib/Awt2dLibraries.gmk
Biggest offender is problem CopyFiles.gmk (but CreateSecurityJars.gmk has a bit too). Basically in each situation where there's a "ifndef OPENJDK", it encloses a block of code that access something in src/closed or make/closed. I did initially try to set a new variable in our build in an attempt to replace these areas with something like: ifndef OPENJDK && ifndef PRIVATEJDK ... but there's apparently no convenient way of doing that in makefiles (conjunctions and disjunctions at the preprocessing level aren't available -- and the workarounds are rather goofy). Duplicating the OPENJDK only code quickly became unreasonable too -- a few of the code blocks are one-liners, but there's a bunch that are much more involved clauses. On Tue, Apr 22, 2014 at 8:23 AM, David Holmes <david.hol...@oracle.com>wrote: > Hi Keith, > > Sorry I have very limited cycles right now, and just had a 4 day Easter > break with anther long weekend ahead :) > > You are right that the src/closed -> CUSTOM_SRC_DIR is somewhat tangential > to your issue. > > The existence checks I suggested would be a check for whatever > file/directory is enough to indicate the "feature" is present. > > Most uses of OPENJDK are really used to indicate !ORACLE_JDK, so > introducing a third variation doesn't really fit. > > Can you give a concrete example of something that highlights this problem > for you and how your proposal addresses it? I may get a better sense of > things with specifics rather than trying to generalize - because I don't > see a general solution without a lot of refactoring. > > Thanks, > David > > > On 22/04/2014 2:42 PM, Keith McGuigan wrote: > >> Hi Mark, et al., >> >> The sad reality of the situation is that there is indeed Oracle-specific >> code in the OpenJDK makefiles, and this code interferes with our >> customization of the JDK. Adding temporary signposts to allow us (and >> others) to avoid this code will not make things worse. It doesn't have >> to be a distribution name -- we call it whatever you like: >> TO_BE_REMOVED, KEITH_IS_A_PITA, whatever -- just something to latch onto >> to deactivate that code when it is not needed. This would provide >> immediate relief to customizing distributors and give Oracle engineers >> time to phase that code into closed makefiles (at which time the >> signposts can be removed completely). >> >> Taking all this code out wholesale instead would be great, and this is >> something I am totally willing to tackle and put the effort in on if I >> was in a position to do so. Unfortunately, since this is not fully >> open-source, I can't do the refactoring needed to move this code into >> the closed directories. And I though I could easily strip the code from >> OpenJDK, this would totally muck with Oracle distribution so any patch I >> would submit would surely be immediately rejected. >> >> Considering that the code is question has been in OpenJDK for about 8 >> years now, I think it's safe to assume that it's not a high priority >> item for Oracle engineers to get this fixed. Which is totally fine, IMO >> -- it's very much a tenant of open source development that he who has >> the itch ought to be the one to scratch it, and different entities are >> expected to have different sets of priorities. No doubt I'm probably >> the first one to complain about this :) >> >> Unfortunately, I'm also in the unfortunate position of having an itch >> (and willing fingernails), but an inability to scratch it. >> >> So, where do we go from here and how can I help in this effort? I >> really do want to help, as this is an immediate problem for me and I >> can't afford to wait years for it to get fixed. I still think that >> signposts are a very reasonable compromise given that: >> (1) It is something that can be done independently and doesn't require >> Oracle engineering resources (other than reviews and shepherding) >> (2) It does not interfere with efforts to move closed code out of >> OpenJDK makefiles >> (3) it can be done quickly >> (4) It does not avoid the Makefile-checking for existence of required >> files/directories (which reduces build-brittleness) >> >> Mark/Dave, if I can't convince you that we should take this path, can >> you please suggest an alternative design? I'm not picky -- if we can >> come up with something else that works then let's do it and I'll start >> on it right away. >> >> -- >> - Keith (itchy) >> >> >> >> >> On Mon, Apr 21, 2014 at 8:23 PM, <mark.reinh...@oracle.com >> <mailto:mark.reinh...@oracle.com>> wrote: >> >> 2014/4/16 14:52 -0700, david.hol...@oracle.com >> <mailto: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 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 think it's wrong, in principle, for OpenJDK source code to contain >> identifiers naming specific vendors of JDK implementations. We're not >> quite there at the moment, but let's please not add any more. >> >> - Mark >> >> >>
