Re: [platform-swt-dev] the build

[Mike_Wilson@xxxxxxx]

I've read all the other replies to my original posting, but Pat seems to be closest to being on the mark, so I figured I'd answer his. 

Eclipse isn't a GUI tool. Eclipse *has* a GUI tool available. The ability to do what Pat is describing below (i.e. start a command line which uses core, jdt, and potentially even vcm) to re-create all of Eclipse is a completely possible. If it was a requirement to be able to re-make the .class files from the command line, it wouldn't be any harder than building a replacement startup app. (I don't know if this has been done, but I suspect that it _hasn't_.). One example of this is the "pocket ide" I'm running on my PocketPC right now, which just uses the jdt chunck of Eclipse to "command line compile" (not quite, since WinCE doesn't actually have a shell ;-) the swt apps I'm playing with.

I agree completely with Havoc's comment that automation is a requirement for building. We do indeed have a "one button" build process which can re-create an Eclipse drop. Currently, this is being done from within Eclipse, but driving it from a command line app really ought to be trivial. I'll make sure that the authors understand that building from the command line is important to linux developers. Note: You will still have to frig with ant scripts to configure it if you don't want to use the GUI front end built into PDE.

The point I was trying to make is that, dealing with the .class files _is_not_the_same_ as building a binary. I'm not trying to offend any linux people here (really!) but the only rational reason to re-build a binary (if you haven't changed the source) is because that's the only way to get it to run on your system. The .class files for Eclipse don't have this attribute.  It makes about as much sense to re-make them as it does to re-paint the icons. As I said in my original post, even if I was porting to a new platform (and believe me, I've done this), I'd start from a working Eclipse somewhere and just remote debug the one I'm trying to get going.

McQ.

Patrick_Dubroy@xxxxxxx Sent by: platform-swt-dev-admin@xxxxxxxxxxx 12/10/2001 05:25 PM Please respond to platform-swt-dev

To:        platform-swt-dev@xxxxxxxxxxx         cc:                 Subject:        Re: [platform-swt-dev] the build

I agree that building Eclipse is much different from building eg. Mozilla.
However, I believe that by not providing a viable means to rebuild the
Eclipse world from the command line, we risk losing many developers.  I
think there are many Linux developers out there who would never consider
contributing to a project if they can't start by building the thing from
scratch.  In fact I know people who as a rule never install binaries that
they didn't build.  Also there is the problem of RedHat and Debian
packages, which as Havoc said rely on maintaining patches to the upstream
sources.

But if Eclipse is a compiler, maybe the package management folks should do
whatever they do with gcc? ie. Use javac to build org.eclipse.jdt.core, and
then build the rest of Eclipse on the command line using the jdt compiler.
It would be cool if we could do that :-)



                                                                                                                                           
                    Mike_Wilson@xxxxxxx                                                                                                    
                    Sent by:                        To:     platform-swt-dev@xxxxxxxxxxx                                                   
                    platform-swt-dev-admin@e        cc:                                                                                    
                    clipse.org                      Subject:     Re: [platform-swt-dev] the build                                          
                                                                                                                                           
                                                                                                                                           
                    10/12/2001 04:38 PM                                                                                                    
                    Please respond to                                                                                                      
                    platform-swt-dev                                                                                                       
                                                                                                                                           
                                                                                                                                           




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:                                  To:                          
   platform-swt-dev-admin@xxxxxxxxxx platform-swt-dev@xxxxxxxxxxx         
   g                                         cc:                          
                                             Subject:        Re:          
                                     [platform-swt-dev] the build         
   12/10/2001 02:41 PM                                                    
   Please respond to                                                      
   platform-swt-dev                                                       
                                                                          





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





_______________________________________________
platform-swt-dev mailing list
platform-swt-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/platform-swt-dev