IcedTea6 1.2 Released!
green at redhat.com
Sun Jul 13 23:42:16 PDT 2008
Mark Wielaard wrote:
> Hi Anthony,
> On Wed, 2008-07-09 at 19:26 -0700, Anthony Green wrote:
>> I got on my flight that day and looked at the IcedTea src tree for the
>> first time, then quickly realized I wasn't going to be able to do this
>> in a vacuum.
>> First question for the IcedTea hackers: where in the tree should my
>> source code live? It looks like there are a few viable spots.
> Yes, there are indeed a couple of ways to extend icedtea/openjdk
> depending on how big and how invasive your change is.
Thanks for explaining this, Mark. I'm proceeding with the overlay
approach. It's taking some time to figure out the build system. Any
tips? Builds take forever.... and I don't know how to test my changes
without starting the build pretty much from scratch.
> For smaller changes the simplest way is to just add a patch under
> patches/icedtea-your-cool-hack.patch and then add that to the
> ICEDTEA_PATCHES in the Makefile.am. Your change will then be applied
> against the openjdk sources before any other building starts and then be
> build as if the change was already part of openjdk itself.
> For larger changes that mainly involve new classes/files/packages it is
> easier to use the overlay mechanism. This is used by Gervill for
> example, and is easier when you need to patch/override binary files
> (like the color profiles). This seems most appropriate to your case. You
> put your files under overlays/openjdk/jdk/src/share/classes/com/package
> that either completely overrides the existing classes there or that adds
> completely new files. If it is a new package then it is necessary to
> combine it with a small patches/icedtea-your-package.patch file to
> adjust the build system to pick up your new package
> (icedtea-gervill.patch and icedtea-rhino.patch give some examples of
> Finally you can build your extension after the core icedtea has been
> build, using the just build icedtea and then adding the extension to the
> jdk-image. This is how the gcjwebplugin applet and netx webstart support
> are done. This does mean that you are basically responsible for the
> build of your extension yourself in a separate target in Makefile.am
> that you then add as a dependency of stamps/icedtea.stamp. And in that
> target you then copy over the results into the correct image dirs. See
> the ICEDTEAPLUGIN_TARGET in Makefile.am for an example or the
> extra-lib/about.jar for a java extension. If you don't like the previous
> solution, then this might be the one to use, although it is a bit more
> work, but gives you more flexibility.
> There are some other things to take care for if your change is actually
> replacing the runtime, like the cacao, zero and shark integration, or
> when it is needed in the bootstrap phase (but perhaps not during the
> phase after that). Then you have to instruct configure.ac to pick up the
> right build pieces and then passing them to the rest of the build
> through the ICEDTEA_ENV and/or ICEDTEA_ENV_ECJ in Makefile.am. But those
> don't apply to your case.
More information about the distro-pkg-dev