[Dev] Planned build/tree changes

Andi Vajda vajda at osafoundation.org
Thu Mar 11 19:41:38 PST 2004

Sorry for the confusion. We are not talking of shifting the burden on
developers to build their own versions of the third party packages either.

The main thrust of the effort is to no longer keep third party sources in our
CVS tree. This is mainly because of the difficulties related to merging
multiple versions of a third party package whose changes we don't necessarily
follow closely using 'cvs import'.

What I'm working on at the moment:
  - separating the building of third parties from the building of Chandler
  - separating the Chandler CVS tree from the third party CVS tree (there
would still be things checked into CVS, for example the files to drive the
third parties build and packaging, patches applied to third party sources,
  - making the building of third parties optional (it actually already is)

The process of building the third parties would still be pretty much automated
except that the step of getting the sources would no longer be done through
'cvs update' but by extracting a tarball.


On Thu, 11 Mar 2004, Kapil Thangavelu wrote:

> I can certainly sympathize and agree with choice of not having third
> party unmodified libs in cvs, but i think that some of the ideas
> presented here go against the expressed goals. namely currently building
> chandler is a fairly automated and sandboxed afair, which is good
> because for some parts the sources of third party libs are either
> bleeding edge and/or hard to build. i think it would be better to keep
> the automation and sandbox environment by integrating download support
> into hardhard of nesc tarballs and remove them from cvs. having to
> download and manually compile any number of libraries in particular
> order is a dentriment to developer adoption. system libraries and
> package managers will often have version conflicts or not have the
> packages at all (conflicts on db-4.2, possibly gcc3.3, not have bdbxml,
> xerces, pathan, or wx2.5 (when that happens)).
> perhaps the question is why do you think this will make it easier to
> develop chandler?
> -kapil
> On Thu, 2004-03-11 at 17:15, Heikki Toivonen wrote:
> > We are planning on doing some pretty major changes to the way people get
> > and build Chandler from source. The major idea is that we want to get
> > rid of the 3rd party libraries from our source tree, especially those
> > that we do not change. We want to encourage developers to not building
> > everything from scratch, and instead just get the binaries for those
> > third party libraries and concentrate on working with Chandler Python
> > source.
> >
> > In other words, the goals/requirements include:
> >     * Make it easy to develop Chandler
> >     * Make it easier to migrate to newer versions of 3rd party libraries
> >     * Use the 3rd party libraries that already exist on your system
> >     * Reduce the CVS repository size
> >     * Discourage building 3rd party packages unless you have to
> >
> > We don't have anything set in stone yet, but some preliminary thinking
> > can be seen here:
> > http://wiki.osafoundation.org/twiki/bin/view/Chandler/WindowsBuild
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> Open Source Applications Foundation "Dev" mailing list
> http://lists.osafoundation.org/mailman/listinfo/dev

More information about the Dev mailing list