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

Jelmer Vernooij jelmer at samba.org
Sun Nov 30 10:13:59 MST 2014


On Sun, Nov 30, 2014 at 05:55:38PM +0100, Ralph Böhme wrote:
> On Sun, Nov 30, 2014 at 03:39:51PM +0100, Jelmer Vernooij wrote:
> > On Sun, Nov 30, 2014 at 03:20:06PM +0100, Ralph Böhme wrote:
> > > 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.
> 
> ah, I missed that one.
> 
> > 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.
> 
> Iirc some of the changes where just not doable for someone not sold to
> python (decorators anyone?).
> 
> > 
> > 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).
> 
> I've looked through our patches on top of waf just recently:
> <https://lists.samba.org/archive/samba-technical/2014-October/103260.html>
Ah, thanks - I missed that earlier.
                                                                           1.5 master
> 64f5e24 build: fix ordering problems with lib-provided and internal RPATHs +   +
> f8c179b build: allow some python variable overrides                        -   -

> 319c2d7 waf: parse LDFLAGS from python                                     +   +
I'm not sure about this change. It's a hack to workaround the fact
that our infrastructure doesn't work properly here. I wonder why
--cross-exec or --cross-answers wouldn't work here, but I'm by no means
an expert on our cross-building infrastructure.

> e1a819e wafsamba: python-config is not always a script.                    -   +
> 0231575 waf: Make samba "ok" with directories for install being symlinks   -   +
I've asked for these two to be cherry-picked into 1.5.

> While you're at it, you could chime in on this one: :)
> <https://code.google.com/p/waf/issues/detail?id=1505>
I'll have a ponder about it; don't feel like I'm qualified enough to have an
opinion at the moment...

Cheers,

Jelmer


More information about the samba-technical mailing list