[Dev] Problems when external/ and/or internal/ out of sync with chandler/

Phillip J. Eby pje at telecommunity.com
Mon Mar 6 14:13:59 PST 2006


At 01:47 PM 3/6/2006 -0800, Heikki Toivonen wrote:
>Because of the way we've set up our builds, there are times when the
>full builds get out of sync with the quick builds. The quick builds
>(i.e. doing make install in chandler/) are the official builds, but this
>does not work for everyone: people using unsupported platforms, or
>people doing development with libraries in external/ and/or internal/.
>
>The problem happens because the APIs in external and/or internal/ have
>changed, but because there are no updated binary tarballs for them yet,
>the callers in chandler/ haven't been updated.
>
>The problem manifests itself by the full builds failing to run
>(=chandler failing to run), or just some tests failing in the full builds.
>
>Obviously we want to minimize the time the full builds are broken this
>way, or avoid them completely if possible.
>
>Some people doing frequent development with external and internal
>libraries have also voiced their opinion that they don't like the build
>failure notices that get sent out because they change some API.

Just FYI, but if I understand the problem correctly, we could bypass this 
whole issue by using EasyInstall, which can download a binary *or* build 
things directly from Subversion, based on the available 
version/requirements/platform, while also allowing people to mix/match 
specialized versions of things.

Of course, implementing that cure may be worse than the disease, at least 
in the short term, since there area a lot of components that aren't 
buildable this way yet.

However, it might be possible to create wrapper shims that wrap the 
existing build mechanism in such a way that EasyInstall still works.  All 
EasyInstall really cares about is that it be able to call "setup.py 
bdist_egg" and get an installable egg in the location it asks for.  The 
biggest hurdles will still be stuff like BDB and wx, though, due to shared 
library issues.  But it might still be worth an attempt, just to find out 
how close we can already get.




More information about the chandler-dev mailing list