[Dev] Planned build/tree changes

[Kapil Thangavelu]

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