[Dev] Problems when external/ and/or internal/ out of sync with
heikki at osafoundation.org
Mon Mar 6 13:47:03 PST 2006
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.
We've discussed this with bear a bit. Here are some of our thoughts.
Here are some things that won't work:
1. Have full build Tboxes do only make tests and no chandler tests.
- won't work because then we wouldn't know when the full builds were
2. Change full build make install step to copy the binary tarballs into
downloads dir. Then doing make install would simply unpack those.
- won't work because when the full and quick builds are out of sync
the make install in chandler/ would cause a prebuilt binary tarball to
be downloaded, which wouldn't work for all platforms and isn't what we
want the full builds to do anyway
Now this might be doable:
3. Put each of the external and internal libs on a dev branch. By
default, the full build would only build trunk. If you passed in DEV=all
it would do the dev branches instead (or DEV=lib1,lib2, ... to limit
it). Tinderbox could do default build and all tests, including chandler,
first. Then do DEV=all build and do only make tests in external/ and
internal/. After the developers were happy with the dev branch they
could merge into the trunk and simultaneously update chandler/ dir. The
only way to update external and internal on trunk would be to merge from
a branch, so that the trunk and branch would not differ after a merge.
Just pulling from svn would only get root level external/ and internal/,
and make sources would then pull the appropriate branches for each of
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 249 bytes
Desc: OpenPGP digital signature
Url : http://lists.osafoundation.org/pipermail/chandler-dev/attachments/20060306/ea4b6472/signature.pgp
More information about the chandler-dev