[Dev] Problems when external/ and/or internal/ out of sync
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