[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
[linux-distros-dev] SDK Build
|
Hi,
I've been thinking for quite a while about re-doing how we build the
SDK. In an ideal world the upstream drops would be exactly what we
needed and we'd just run ant or whatever to build them and be done with
it. That's not the current situation and while I personally am
committed to making it so, it's not always going to be possible to have
all patches upstream before a major release.
We currently have 15 patches plus other workarounds in the Fedora
Eclipse SDK build. See [1] for the gory details.
Did you read that? A lot of stuff, eh? So what can we do to fix it?
Ben Konrath wrote a few ideas up about 6 months ago. I'll present them
here with some other ideas interspersed:
1) Bootstrap pde.build so that the build.xml files can be generated at
build time rather than including pre-generated build files
This will allow third parties to easily change parts of the build
without having to patch the pre-generated build.xml files.
2) Do not hard code arch strings in fragments but instead generate the
fragments at build time.
This would allow us to build on other arches without the hoops through
which we currently have to jump.
3) Use the sourceIncluded drop to generate the binary builds so that
third party builds, such as the ones we generate, use the same build
process as the eclipse.org builds.
Ben raises another interesting issue: eclipse.org could have some kind
of certification program whereby third party builds can be given an
official approval if the build passes all of the unit tests. Thoughts?
One thing to keep in mind is that we're already kind of late in the game
for 3.4. If we want to fix these issues, we'll need to move fast.
An easier than the above options (and a short term solution) is what Ben
started with the eclipse-build project in linuxtools SVN [2]. He
proposed creating source drops for use by Linux distributions similar to
ooo-build (OpenOffice.org builds for Linux distributions). I've been
experimenting with it from a different angle: starting with the
build.xml and build.sh scripts that releng uses but stopping before the
generation of the build.xml files. This is similar to the first idea
presented above. It's slow going, but I'm getting there. I'll check
the small build.xml file I have into SVN when I get a chance.
Is anyone interested in collaborating on this project? We can easily
experiment there and then take what works well and propose it for
inclusion in the various projects.
Andrew
[1]
http://cvs.fedoraproject.org/viewcvs/devel/eclipse/
Build patches:
==============
1) 1 patch to build swttools.jar as part of the build
https://bugs.eclipse.org/bugs/show_bug.cgi?id=90364
- I'm not really sure what's up here
2) 1 patch to fix the update fragment build.xml to not be just x86
I don't see why this build.xml gets generated to contain just x86 but it
requires some investigation
3) 1 patch to the launcher to allow us to move it
- this allows us to move the launcher to /usr/bin and ensures that the
configuration directory (which contains the JNI .sos) is in /usr/lib (or
/usr/lib64) and is seen
- this needs investigation and potential re-working with upstream
- ideally we wouldn't need to modify the launcher at all
- related: https://bugs.eclipse.org/bugs/show_bug.cgi?id=185826
4) 1 patch to fix a double free in the launcher
https://bugs.eclipse.org/bugs/show_bug.cgi?id=198840
- already applied upstream ... need to investigate why it's being
patched in the feature if it's already applied
5) 1 patch to add $JAVA_HOME to build.sh
- I'm not sure why this is being done. Need to investigate.
"Customization "patches:
========================
1) 2 patches to use the system tomcat (5.5.x) and not the included 4.4.x
- while it would be nice to have upstream move to 5.5.x, it didn't look
like it was going to happen:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=98371
- I know that jetty is used for help as of 3.3, but I didn't want to
diverge too much from upstream by removing it in Fedora. Ideally it'll
get removed in 3.4 and we can also get rid of it.
2) 3 patches to add arch support for ppc64, s390, s390x, sparc, and alpha
- yes, the fragments for these arches should be contributed to
eclipse.org but realistically I don't think we can commit to that. This
wouldn't require patches if we re-did some parts of the build (see
potential solutions above).
3) 1 patch to ecj to always generate debuginfo when building an RPM
- this was added by the gcj guys.
4) 1 patch to add generate PDE build scripts
- this needs to be tackled as part of a larger effort to see how we can
make building additional plugins headless easier
5) 1 patch to ecj to allow it to be used by the gcj frontend
- ...
6) 1 patch to generate 1.6 bytecode on a 1.7 VM (IcedTea/OpenJDK)
- this will obviously be fixed when 1.7 VMs get closer to release
7) 1 patch to increase the default PermGen size
- ...
So that leaves us with 5 build-ish patches and 10 customization-ish
patches. I say "-ish" since they're not all strictly build or
customization.
Now let's look at other build things we do that could be considered
patching:
1) set java5.home to java.home
- the way upstream builds with multiple JVMs doesn't really work for the
distros (well, not Fedora at least)
2) some more sed'ing for the tomcat version change
- see above
3) some changes to the liblocalfile Makefile
- these (adding -O2 and -g) should probably go upstream
4) removing launchersrc.zip
- we should see what's up here
5) sed'ing to the launcher library to make it relocatable and to make
the configuration directory be in a different location
- ugh
6) sed'ing to use system-installed JVM javadocs and not Sun http ones
- the Fedora build system works offline. I think other distros systems
work in a similar fashion
7) changing the build to output some logs to stdout instead of files
https://bugs.eclipse.org/bugs/show_bug.cgi?id=144942
- it would be nice to have a patch to do this so it could be included
upstream and then we could just set a flag
8) removing existing .sos and binary launcher
- yeah ...
9) some more hacks to fix ia64 and get other platforms
- this is ugly
- see below for one possible way forward
10) lots of symlinking
- we (Fedora) use the system jars for dependencies and not the
Eclipse-supplied ones
- yes, this makes for a bit of a headache trying to get OSGi manifests
into the dependencies
[2]
http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.linuxtools/eclipse-build/trunk/?root=Technology_SVN
