[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [platform-swt-dev] the build
|
Being involved with open source since the mid 80's, I think Havoc is spot on.
Mike is also correct, in that the best tool to build Eclipse is Eclipse.
This is all very analogous to the bootstrapping of the GNU compiler tool
chain which is a three stage build, done by the command "make bootstrap"
for GCC on Unix systems: 1) build with whatever you have. 2) Have the tool
rebuild itself, saving output. 3) Have the rebuilt tool from stage 2
rebuild itself again, saving another copy of the output, and compare
bit-for-bit equality. Any bit-rot between stage 2 and 3 indicates a real
problem.
Now obviously, there must be a scripted solution to perform that work,
which will be done over and over again. "Scripted" might mean running
Eclipse or whatever GUI-based tool in headless mode, or just typing "ant"
and hit return (which would be readily accepted) for a simple but complete,
un-staged build. For the more adventurous (well, less, actually, as it
verifies the build is correct) among us, as well as for Open Source
distributors, there must also be the "make bootstrap" equivalent.
That much said, I haven't built Eclipse yet and have no idea what PDE is
;-) The point is that I, like any Eclipse newbie, should not need to know
until I feel the urge to improve whatever PDE does.
-- Leonard
At 16:38 10.12.2001 -0500, you wrote:
Ok. Time for me to wade into this...
I think it's a mistake to look at rebuilding the C code for Eclipse in the
same light as rebuilding all of the Java code.
First off, you ought to be able rebuild the launcher and any .so files
which come with Eclipse using command line tools. If nothing else, there
ought to be an easilly configurable, well documented script file somewhere
(in some well known place) which can do it for you. What I would like for
this, is a process which is "intuitive" to the linux community. Just "make
and go". Whatever.
Having said that, there is _no_better_tool_ for building the java code for
Eclipse than Eclipse itself. Period. Asking someone to build all of
Eclipse using an external command line driven tool is pretty much
equivalent to asking them to paint an image by manually typing in the XBM
data. Wanting to "rebuild the whole thing with [y]our compiler and tools"
doesn't make sense if the thing itself is the thing which should do the
building.
In addition, given the size of Eclipse and the fact that the Java code is
almost entirely platform neutral, there really isn't ever a reason to
compile all of it. In some sense, you should think of the C code as the
only real "source". The Java .class files are more like a wad of data
which the C code eats. It turns out there *is* a way to recreate these
files from the description (the .java files), you just don't need to do
this very often. The example you gave of wanting to fix a bug in something
other than SWT is a good one: PDE is exactly what you need to do this. I
can indeed guess how to do it manually, but it's definately not going to
be less "difficult to rebuild", it's going to be much harder. In fact, the
main reason for the existance of PDE is for that very reason: to simplify
the task of building Eclipse.
Even for porting to another platform, by far and away the easiest way to
develop is to start on a platform which does run and use the remote debug
facilties to get to the target you want to run on.
In some sense, the disconnect here is much like the original leap between
running in Smalltalk and running CC. I'm certainly not going to argue that
there is a steeper learning curve at the start, but it is definately worth it.
McQ.
Havoc Pennington <hp@xxxxxxxxxx>
Sent by: platform-swt-dev-admin@xxxxxxxxxxx
12/10/2001 02:41 PM
Please respond to platform-swt-dev
To: platform-swt-dev@xxxxxxxxxxx
cc:
Subject: Re: [platform-swt-dev] the build
Boris_Shingarov@xxxxxxx writes:
> And your last question, building the rest of Eclipse. Why would you ever
> want to do it???
The idea of open source is that you change the source, rebuild, then
get a new improved executable. That implies the ability to rebuild,
obviously. If rebuilding isn't easy, there's no motive to bother to
change the source. So it'll be hard to get contributors.
More concretely for Red Hat, the way Red Hat packages work is that we
unpack the pristine/unmodified upstream source code, apply Red Hat
specific changes or improvements, then rebuild the whole thing with
our compiler and tools. To use Eclipse we really want to be able to
rebuild the whole thing from the command line. This is absolutely
fundamental to the release/devel process of every Linux distribution I
know of.
This ensures we are always using our compiler toolchain, and keeps our
changes separate from the original, so we can incorporate new upstream
versions without losing our changes. It also ensures that we always
have binaries that definitely reflect the shipping source code
(i.e. you can't get the binaries out of sync with the code). The GPL
requires that the source match the binaries, and though the Eclipse
license doesn't, our process reflects this GPL requirement.
But ignoring Red Hat's exact process, there's a cultural issue - you
have to understand that the shipped product for most open source
projects is the source code, not the binaries. Part of the reason for
this is that open source projects typically support a huge number of
platforms - so that's also why you see feature-based configure scripts
instead of simple "if solaris then XYZ" kind of statements, and why
you see people immediately noticing "this will fail on IA64" kind of
issues.
And just as a practical matter, even if someone is primarily hacking
on SWT, they'll probably find bugs in other bits of Eclipse that need
fixing in the course of debugging things, and want to step into that
source code in the debugger, make a patch, rebuild, test, and submit
the patch, right. But if it's difficult to rebuild and deploy the
changed code, there's a barrier to entry there that will stop many
people from finishing the task.
Havoc
_______________________________________________
platform-swt-dev mailing list
platform-swt-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/platform-swt-dev