Re: [orbit-dev] building orbit bundles

[Ben Konrath <bkonrath@xxxxxxxxxx>]

On Sat, 2007-01-20 at 21:07 -0500, Jeff McAffer wrote:
> 
> Ben Konrath wrote on 01/20/2007 02:55:39 PM:
> 
> > On Thu, 2007-01-18 at 23:23 -0500, Jeff McAffer wrote:
> > > We currently get the ICU binary and source bundles directly from
> > > the ICU team and simply include them in the build.  No ziping,
> > > tarring, jaring, slicing, dicing or even julien'ing.  The complete
> > > built bundles do happen to be in CVS somewhere to facilitate 
> > > repeatable builds but they are just stashed there in complete, 
> > > built form.  Does a source JAR in the form we currently ship work
> > > for you? 
> > 
> > No, there's no way generate the build scripts with "src" plugins so
> > we can't build it.  
>
> I'm not sure what you mean here.  If you get a source jar from someone
> do you want to "build" it too?  

Yeah, for bundles that don't ship as part of the Eclipse SDK it would be
nice to have a way to create binary bundles from source bundles. Right
now we have a crazy hacked up set of releng scripts to build these
plugins but we can't use the source bundles because they don't contain
enough information to generate the build scripts. So we have to use cvs
snapshot which becomes very annoying when developers don't tag cvs.

> Yes, this is a confusion but Eclipse is by no means unique in its
> interpretation of "source".  Our model is that the source bundles
> include whatever is needed to develop code that *uses* the
> corresponding binary bundle.  That is, the source bundles are form of
> SDK.   

Yeah, I know that and you know that (and probably everybody on this list
knows that), but when I ask plugin developers to provide a source drop
that I can build, they often tell me that I should use the source
bundle. They aren't aware that its primary purpose is for development
not building.

> I'm still not seeing the issue here.  Are you saying that the code
> used to generate the build files to build ICU in fact uses ICU?  Do
> you know where that dependency is coming from?  

To build Eclipse you need the binary ICU bundles, and to build the ICU
bundles you need Eclipse to generate the build files ... and that gives
a cycle in the build dependency tree. 

> ICU should not have to do anything too complicated to build since it
> does not depend on any other bundles.  Perhaps another approach is for
> them to supply pregenerated build files? 

We currently patch the ICU build with pre-generated build files but we
managed to bootstrap our build tree so we'll probably start relying on
our eclipse packages to build the ICU bundles. But to answer your
question, yes, if ICU provided pre-generated build files, the problem
would go away. What's the best way to pursue this? I suspect I should
file a bug with the ICU team, but I also suspect that the bug will get
ignored as per my past experience. But, c'est la vie :)

> I understand but we cannot be responsible for building ICU.  Who knows
> how they decide to build there stuff.  For example they might be one
> of those wild-eyed Maven guys (ok ok, I'm joking :-) in which case we
> would have to accomodate their build infrastructure embedded in the
> middle of ours. 

Seems reasonable. I guess we'll just have to continue doing what we've
been doing :)

> Right.  That seems reasonable.  However you are going to have similar
> issues with any bundle/JAR that is built with PDE build or Maven

Yep, we'll have a problem with bundles/jars build with PDE build. Not
sure about bundles built with Maven yet.

> (actually, is Maven built with Maven?  If so, how do you get around
> that circularity for JARs built using Maven?). 

For Maven we just bootstrap that build system by creating a custom maven
bootstrap mode, recompiling all the dependencies and then compiling
maven again.

> As a point of interest, what do you use for a Java compiler?  How is
> that built? 

We currently use GCJ which is a C app to compile jdt.core for the first
bootstrap stage of the eclipse build. And we end up using jdt.core as
the system javac. Since jdt.core is replacing the GCJ C app in the next
release of GCC, there will be a cycle in the build tree that we'll have
to deal with until javac (a C++ app) from the openjdk project is
released under the GPL.

Thanks for all help here Jeff.

Cheers, Ben