JDK-8025705
Keith McGuigan
kmcguigan at twitter.com
Wed Apr 23 11:23:25 UTC 2014
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 OpenJDK makefiles be in a state such
that custom distribution code can be added (in make/closed, src/closed, or
some such alternative location) without having to perform surgery on the
Makefiles and maintain the private changes. The mechanism is already in
place,it's just some leftover OracleJDK that hasn't made it out of the open
makefiles yet. If we could just cordon that off somehow, then anyone could
make a custom distribution by augmenting OpenJDK with 'closed' style
repositories -- without having to maintain private, unrelated edits to jdk
Makefiles.
On Wed, Apr 23, 2014 at 12:10 AM, David Holmes <david.holmes at oracle.com>wrote:
> 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
>>
>>
>>
>>
More information about the build-dev
mailing list