[Dev] Problems when external/ and/or internal/ out of sync with
bear at code-bear.com
Mon Mar 6 13:57:18 PST 2006
On Mar 6, 2006, at 4:47 PM, Heikki Toivonen wrote:
> 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
agree - a non-starter -1
> 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
I could go for this since it is rare that someone is both developing a
changed library and on a non-supported library. But I actually like #3
better so would still give this a -1
> 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
> it would do the dev branches instead (or DEV=lib1,lib2, ... to limit
> it). Tinderbox could do default build and all tests, including
> 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
> 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
> and make sources would then pull the appropriate branches for each of
> the libs.
I like this one a lot, with one small change :)
The change I would make is what we started to discuss on #chandler.
That there be a environment var that controls what libraries are pulled
from the branch (heikki suggested something like DEV=m2crypto,zanshin
which I like.) This allows a dev to work on the lib they are
interested in and *not* get hung up on other branch work for libs they
are not interested in.
Also, to clarify something, *all* release, checkpoint, milestone,
whatever is done only to the trunk and that the merge only happens from
the branch to the trunk. This allows all new library updates to flow
in one direction and will greatly simplify the merge mechanics.
Build and Release Engineer
Open Source Applications Foundation (OSAF)
bear at osafoundation.org
bear at code-bear.com
PGP Fingerprint = 9996 719F 973D B11B E111 D770 9331 E822 40B3 CD29
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 186 bytes
Desc: This is a digitally signed message part
Url : http://lists.osafoundation.org/pipermail/chandler-dev/attachments/20060306/b7cb43ce/PGP.pgp
More information about the chandler-dev