[PATCH 2/2] Support updating waf from the update-external script.

[Jelmer Vernooij]

On Sun, Nov 30, 2014 at 03:20:06PM +0100, Ralph Böhme wrote:
> Hi Jelmer,
> 
> On Sun, Nov 30, 2014 at 02:09:48PM +0000, Jelmer Vernooij wrote:
> > Signed-Off-By: Jelmer Vernooij <jelmer at samba.org>
> > ---
> >  lib/update-external.sh | 5 +++++
> >  1 file changed, 5 insertions(+)
> > 
> > diff --git a/lib/update-external.sh b/lib/update-external.sh
> > index 7c55321..e3c0872 100755
> > --- a/lib/update-external.sh
> > +++ b/lib/update-external.sh
> > @@ -51,4 +51,9 @@ svn co http://mimeparse.googlecode.com/svn/trunk/ "$WORKDIR/mimeparse"
> >  rm -rf "$WORKDIR/mimeparse/.svn"
> >  rsync -avz --delete "$WORKDIR/mimeparse/" "$LIBDIR/mimeparse/"
> >  
> > +echo "Updating waf..."
> > +git clone https://code.google.com/p/waf.waf15/ "$WORKDIR/waf"
> > +rm -rf "$WORKDIR/waf/.git"
> > +rsync -avz --delete "$WORKDIR/waf/" "$THIRD_PARTY_DIR/waf/"
> > +
> 
> pardon my ignorance, but how does this deal with the six or seven
> patches we have on top of waf 1.5 ?

It will overwrite patches, just as buildtools/update-waf.sh would have done; this
patch doesn't change any of that, it just moves the update logic to a different
script. I'll send in a patch to remove that script now that update-external.sh
can deal with it.

We really shouldn't be shipping patches on top of waf, but either working
around issues in wafsamba/ or sending patches upstream and then pulling those in.
Keeping our own patches around makes it hard to follow upstream.

The only reason we have an unpacked waf (rather than the compressed binary
that upstream recommends shipping) in our source tree is because Debian
requires that the preferred source is shipped.

For the existing patches, I'm planning on doing that (forwarding upstream).

Cheers,

Jelmer