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

[Mike Taylor]

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
broken

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

it would do the dev branches instead (or DEV=lib1,lib2, ... to limit

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

a branch, so that the trunk and branch would not differ after a merge.

and make sources would then pull the appropriate branches for each of
the libs.

default, the full build would only build trunk. If you passed in DEV=all it). Tinderbox could do default build and all tests, including chandler, only way to update external and internal on trunk would be to merge from Just pulling from svn would only get root level external/ and internal/,

I like this one a lot, with one small change :)





---
Bear

Build and Release Engineer
Open Source Applications Foundation (OSAF)
[EMAIL PROTECTED]
http://www.osafoundation.org

[EMAIL PROTECTED]
http://code-bear.com

PGP Fingerprint = 9996 719F 973D B11B E111  D770 9331 E822 40B3 CD29

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.

PGP.sig
Description: This is a digitally signed message part

_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

Open Source Applications Foundation "Dev" mailing list
http://lists.osafoundation.org/mailman/listinfo/dev