JDK-8025705
David Holmes
david.holmes at oracle.com
Sat Apr 26 11:24:21 UTC 2014
Keith,
Given
ifndef OPENJDK
currently really means
ifdef ORACLEJDK
all I'm saying is that you should be setting OPENJDK=true to exclude
much of the ORACLEJDK stuff - which is what you wanted. Don't let the
default value for it be set based on whether src/closed is found - force
it to true!
There is some OracleJDK stuff explicitly referenced via src/closed
whatever. For those things they should either be inside "ifndef OPENJDK"
or else there should an existence test. This should also exclude them
from your build.
For your custom sources that you want to include in the build, then you
have to write and maintain the rules for that in your custom makefiles -
that's why we have the custom makefiles (yeah it ain't complete or
perfect but it can be worked on).
I don't see that adding ORACLEJDK as a variable makes any practical
difference, or enables anything not currently doable by setting OPENJDK.
David
-----
On 24/04/2014 10:34 PM, Keith McGuigan wrote:
> On Wed, Apr 23, 2014 at 8:51 PM, David Holmes <david.holmes at oracle.com
> <mailto:david.holmes at oracle.com>> wrote:
>
> On 23/04/2014 9:23 PM, Keith McGuigan wrote:
>
> 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.
>
>
> I see no short-term fix for this beyond what I suggested, as an
> alternate to putting in the ORACLEJDK variable. But you would have
> to maintain that change in your private repo - I see no way around that.
>
>
> So let me get this clear then. There is Oracle code in the makefiles.
> That code interferes with creating an alternate distribution based
> upon OpenJDK using the "alternative source" mechanism. These things we
> agree upon, yes?
>
> What you telling me is that you will prevent me from adding a harmless
> macro to the OpenJDK makefiles that will simply identify the Oracle
> closed, proprietary code so that I (and anyone who is not Oracle or it's
> licensees) can skip over those parts of the makefile. And instead your
> solution is that I need to do all of this in a private repository and
> maintain this code myself, going forward forever, until Oracle gets
> around to removing the proprietary code from the makefiles (code that
> has been present for 7+ years and doesn't look to be going anywhere).
>
> All so that you can avoid seeing a macro that won't do you any harm or
> add to your burden in any way.
>
> Do I have this all correct? is this how cooperative, open development
> occurs in OpenJDK? Oracle gets to use features to make a custom
> distribution, but no one else can? This hardly seems fair.
>
> --
> - Keith
>
>
> Given that:
>
> ifndef OPENJDK
>
> actually, implicitly means
>
> ifdef ORACLEJDK
>
> then all non-Oracle builds must presently declare themselves to be
> OPENJDK implementations. To which they can add specific customizations.
>
>
> 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.
>
>
> You simply need to leave OPENJDK set to true to achieve that
> cordoning off.
>
> Even if we move all OracleJDK specific stuff out of the open
> makefiles a completely clean separation may not be possible:
> - the customization hooks can not be everywhere and different
> customizations may have different requirements
> - if there are chunks of OpenJDK code (ie code currently part of
> both OpenJDK and Oracle JDK) that are not wanted in your custom
> build then you will still need to maintain private makefile changes
> to exclude them. To fix this will need additional "modularization"
> of the build with feature-selection (though not in a way that would
> violate the platform specifications).
>
> David
> -----
>
>
>
>
> On Wed, Apr 23, 2014 at 12:10 AM, David Holmes
> <david.holmes at oracle.com <mailto:david.holmes at oracle.com>
> <mailto:david.holmes at oracle.__com
> <mailto: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>
> <mailto:david.holmes at oracle.__com <mailto:david.holmes at oracle.com>>
> <mailto:david.holmes at oracle.
> <mailto:david.holmes at oracle.>____com
>
> <mailto: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>>
> <mailto:mark.reinhold at oracle.
> <mailto:mark.reinhold at oracle.>____com
> <mailto:mark.reinhold at oracle.__com
> <mailto:mark.reinhold at oracle.com>>>
> <mailto:mark.reinhold at oracle
> <mailto:mark.reinhold at oracle>.
> <mailto:mark.reinhold at oracle
> <mailto:mark.reinhold at oracle>.>______com
>
>
> <mailto:mark.reinhold at oracle.
> <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>>
> <mailto:david.holmes at oracle.
> <mailto:david.holmes at oracle.>____com
> <mailto:david.holmes at oracle.__com
> <mailto:david.holmes at oracle.com>>>
> <mailto:david.holmes at oracle
> <mailto:david.holmes at oracle>.
> <mailto:david.holmes at oracle
> <mailto:david.holmes at oracle>.>______com
>
>
> <mailto:david.holmes at oracle.
> <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