Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [platform-swt-dev] the build


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



Back to the top