Re: [platform-swt-dev] the build

[Havoc Pennington <hp@xxxxxxxxxx>]

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