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 broken 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 the libs. -- Heikki Toivonen
signature.asc
Description: OpenPGP digital signature
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ Open Source Applications Foundation "Dev" mailing list http://lists.osafoundation.org/mailman/listinfo/dev
