sdt patches split up for 6 and 7

[Andrew Hughes]

----- Original Message -----
> On Thu, 2012-08-16 at 19:29 -0400, Andrew Hughes wrote:
> > > I assume this is fine for 6, since there is no release pending. I
> > > didn't see a release branch for the icedtea7 tree yet (I assume
> > > that would
> > > be called release/icedtea7-2.3), so I am waiting for that to be
> > > created
> > > to check this in (only on trunk, it isn't very important to get
> > > into a
> > > release soon, it is mainly cleanup, no functional changes except
> > > for
> > > the addition of an extra testcase).
> 
> Just to be clear I am not checking in code at an inopportune time.
> Is the above OK?

Depends what we're talking about.  IcedTea6 fine, please wait for 7
to branch (I'll try and get to it this afternoon, but the weekend
is nearly here already...)

For 7, I'd rather the code changes were in the forest and IcedTea7
just set the right options.  See below.

> 
> > > On irc Andrew Hughes suggested that for 7 (and 8?) I could also
> > > add
> > > the patches directly to the icedtea-forest/hotspot and separate
> > > commits.
> > > I'll like to do that after they get committed into the tree,
> > > since I
> > > know it works there and I am not too familiar with the forests.
> > > So it
> > > would be good to catch any mistakes in the transfer.
> > 
> > The only reason the SystemTap patches were kept in IcedTea7 is
> > because
> > they were conditional and so I believe they shouldn't be applied if
> > SystemTap wasn't available.  If this is not the case, they should
> > be
> > added to the forest and removed from IcedTea7, as is already the
> > case
> > with every other non-conditional patch.
> > 
> > This makes the patches available to those who use the forest but
> > not the IcedTea build infrastructure.  IcedTea7 itself is a
> > consumer
> > of the forest.
> 
> When proposing the patch on hotspot-dev I moved the conditional into
> the
> hotspot build make files (that is patches/sdt-make.patch). So it get
> build when sys/sdt.h is available and you can disable it, or point at
> a
> non-standard location, by setting SDT_H_FILE (yeah, not as nice as in
> icedtea currently, but that is all the hotspot build infrastructure
> really offers).

So sounds like:

if ENABLE_SYSTEMTAP
ICEDTEA_PATCHES += patches/systemtap.patch
endif

can be replaced by:

if ENABLE_SYSTEMTAP
ICEDTEA_ENV += \
<whatever options enable SystemTap>
endif

No?

I'd prefer the actual code changes are in the forest so they get merged
automatically when that is updated, not when IcedTea is built.  They also
then show up in our diffs and we know they are not upstream.

> 
> It would be good to keep the icedtea conditional since the configure
> check is more extensive and catches issues early instead of at build
> time. But it isn't a requirement anymore. It is a prerequirement for
> the
> tapsets and the jtapstest suite. Those are independent from the SDT
> probes though (the SDT probes are independent from systemtap, they
> can
> also be consumed by for example GDB so you can put a breakpoint on
> them).

I wasn't suggesting removing the conditional.  Just that you could apply
the patch as it would have been applied to OpenJDK in the forest, then
use IcedTea to set appropriate build options.

> 
> > > How does one build the tree against the tip/you own branch of
> > > the forest?
> >
> > I'm sorry.  I don't really understand your last question.  Perhaps
> > you could rephrase it?
> 
> It is just that I never worked against a forest from the icedtea
> build.
> How does one point the icedtea build at the forest you are working
> against? I assume it is a configure option. I see --with-hg-revision.
> Is
> that it? What do you use as argument?

IcedTea always builds against the forest.

--enable-hg and --with-hg-revision can be used to checkout a tree
from hg during build, rather than using tarballs.  It's not been used
in a while though, it's still using fclone which needs fixing.

--with-openjdk-src-dir is what I tend to use as you can point it at your
existing checkout. That's how I handle icedtea6-hg (the next release of
OpenJDK6).

These may well break the build though, as they are building against potentially
untested revisions.

As default, IcedTea7 grabs specific revisions from the Mercurial forest
as tarballs and builds them.  These revisions are only updated when new
ones are known to work with IcedTea7.

CORBA_CHANGESET = 7541673f1f87
JAXP_CHANGESET = fc3d8d956b08
JAXWS_CHANGESET = fd4311742772
JDK_CHANGESET = f46deb5db4f9
LANGTOOLS_CHANGESET = ba340b8fe8cf
OPENJDK_CHANGESET = 7e0976a9c562

        if ! echo "$(OPENJDK_SHA256SUM)  $(OPENJDK_SRC_ZIP)" \
          | $(SHA256SUM) --check ; \
        then \
          if test "x$(enable_downloading)" = "xyes"; then \
            if [ -e $(OPENJDK_SRC_ZIP) ] ; then \
              mv $(OPENJDK_SRC_ZIP) $(OPENJDK_SRC_ZIP).old ; \
            fi ; \
            $(WGET) $(OPENJDK_URL)/archive/$(OPENJDK_CHANGESET).tar.gz -O $(OPENJDK_SRC_ZIP); \
            if ! echo "$(OPENJDK_SHA256SUM)  $(OPENJDK_SRC_ZIP)" \
              | $(SHA256SUM) --check ; then \
              echo "ERROR: Bad download of OpenJDK root zip"; false; \
            fi; \
          else \
            echo "ERROR: No up-to-date OpenJDK root zip available"; exit -1; \
          fi ; \
        fi ;

You can override individual zips with --with-x-src-zip, as the builders do.

To be honest, it's probably easiest if you commit the patch to the forest
and set the configure options in IcedTea7 as suggested above.  Then I'll bump
the revisions when we're ready and drop the IcedTea7 patch, as that all needs to
be done in sync.  At present, IcedTea7 is set to point at u6 ready for the branch,
rather than the tip of HEAD.

> Feel free to point at the fine documentation if I missed it.
> 

The INSTALL file is your friend.

> Thanks,
> 
> Mark
> 

-- 
Andrew :)

Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

PGP Key: 248BDC07 (https://keys.indymedia.org/)
Fingerprint = EC5A 1F5E C0AD 1D15 8F1F  8F91 3B96 A578 248B DC07