proposal: merge waf build of s4 to master

tridge at tridge at
Mon Apr 5 05:26:26 MDT 2010

Hi Volker,

 > I would call these ones bugs in the current

yes, it's all fixable. The level of effort involved in fixing all
these things may not be small however.

I think Kai has noticed some other s3 build bugs as well while he's
been developing the waf build for s3.

 > >  - bundled library renames, so they can safely install on a system
 > >    that has packages that rely on talloc, tdb etc without breaking
 > >    their system
 > What does that mean?

I tried to explain it a bit on the wiki page:

The problem is this. Imagine you are building tdb as a shared lib in
Samba3, and the build decides to use the in-tree version instead of
the system version as the system version is too old.

So you end up with Then you install that in

Now you have a problem. What do you put in If you put
/usr/local/samba/lib first then any existing apps that depend on tdb
will get the new version. That will be a version they've never been
tested against. If you don't put /usr/local/samba/lib first then Samba
will get the system version.

So the solution is to auto-rename the library to something else. In
the waf build a suffix is added, based on the name of the package
being built. So if you are building as part of a s4 build
then you end up with That guarantees no conflicts,
and can contains paths in any order.

 > What blocks us from putting that into as well?

nothing. We could have just kept going with autotools, and s3 can keep
going with autotools if that is what we decide to do as a team.

I'm hoping that the new build system will make life easier for
developers however. 

 > >  - detection of conflicts between system and in-tree libs, so you
 > >    don't end up with two instances of talloc in one binary (and thus
 > >    possible corruption)
 > Again, this is a bug in the

sure, and it is fixable, though I don't think its a trivial patch to
get right.

Cheers, Tridge

More information about the samba-technical mailing list