JDK-8025705

[David Holmes]

Hi Keith,

Okay ... so you don't set OPENJDK and thus from the make logic 
perspective you are implicitly ORACLE_JDK. So first question: why don't 
you set OPENJDK and then add blocks guarded by MY_JDK (or whatever) for 
your custom stuff?

Second, the way to get a disjunction is to use the text functions eg 
(untested but you should get the gist):

// OR
ifeq (true, findstring( $(OPENJDK) $(MYJDK), true)

// not-OR
ifneq (true, findstring( $(OPENJDK) $(MYJDK), true)

It's not as trivial as || etc but not too horrendously ugly :)

Does this help?

David

On 22/04/2014 11:10 PM, Keith McGuigan wrote:
> 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.holmes at oracle.com
> <mailto:david.holmes at 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.reinhold at oracle.com
>         <mailto:mark.reinhold at oracle.com>
>         <mailto:mark.reinhold at oracle.__com
>         <mailto:mark.reinhold at oracle.com>>> wrote:
>
>              2014/4/16 14:52 -0700, david.holmes at oracle.com
>         <mailto:david.holmes at oracle.com>
>              <mailto:david.holmes at oracle.__com
>         <mailto:david.holmes at 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
>
>
>