sdt patches split up for 6 and 7

Mark Wielaard mjw at
Fri Aug 17 02:06:32 PDT 2012

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?

> > 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).

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

> > 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?
Feel free to point at the fine documentation if I missed it.



More information about the distro-pkg-dev mailing list