running autogen-waf.sh as part of waf dist

[tridge at samba.org]

Hi Simo,

 > Yes I saw it, but didn't realize you proposed waf dist as a standard way
 > to build tarballs when not using waf, given it copies all the waf stuff
 > within the tarball.

I added the ability to do this, but I haven't actually proposed as yet
that we adopt it as the standard approach. I just didn't want anyone
to think that I was presuming stage 3 would happen, which would be one
interpretation of linking configure to the waf build.

 > Speed-wise looks very promising, I still need to get used to where
 > libraries and binaries are placed and how they are called, ./bin has
 > become a bit of a mess imo, with lots of directories and symlinks.
 > 
 > I was wondering why you haven't adopted a more common approach of
 > building into a ./build directory for the various .o/.a files and then
 > put the resulting binaries into ./bin and ./bin/lib without a deep
 > hierarchical set of directories under ./bin

Most waf projects use build/ instead of bin/. I chose bin/ as it
worked with our existing test suite, and it meant that "rm -rf bin" is
a easy to remember "clean everything".

I could make it use a build/ and bin/ split as you suggest, and I
think that would work, although I don't see it as really making much
of a difference. If there is a general consensus that we need to keep
bin/ tidy in our trees for some reason I could put the time in to do
this, but otherwise I'd rather spend the time on something else. I
don't see having subdirectories in bin/ being much of an issue. 

Also, it couldn't actually be build/ as long as we kept the existing
build system working in parallel, as build/ contains lots of important
files for the s4 autoconf build. That just means someone would need to
propose a different name. 

 > > We still need to sort out if the standard build for the dependent libs
 > > should also be waf if we move to stage 3 for s4. I think we should,
 > > but you had some concerns about that. I'd be interested in knowing if
 > > you are happier with the idea of waf for ldb now you've had a chance
 > > to try it.
 > 
 > In general it is not a big deal for me, if I have to be selfish I can
 > see that both Fedora and RHEL do not really have issues with python as a
 > dependency, but my concerns are more for people building for embedded
 > systems or old Unices. If you have to use S4 you pretty much need python
 > anyway, but the sub-libraries really don't, it would just be a build
 > complication.

I really doubt this will be a problem. Building python is very
easy (strangely, I find building perl a lot harder).

I don't see the python requirement as being much beyond our existing
requirement of the right version of autotools and our requirement for
GNU make (all our standalone libs require GNU make now).

 > I think we need to carefully consider how much this dependency affects
 > usability for non-AD-Server code.

Are you refererring just to the python dependency here, or are you
concerned about something broader?

 > > If you like, we could create a ldb-waf build in the build farm first.
 > 
 > Yes, this would be a good idea in any case.

I was proposing doing this instead of the existing ldb build in the
build farm just because that existing build is not much use at the
moment, so I didn't see that we lose anything by replacing it.

If you think you may have some time to fix the ldb autotools build,
then we could of course leave it up. I just assumed you didn't plan on
doing that.

 > 
 > Even better if we could do this by building each library dependency
 > first so that we can test the full shared library approach.

hmm, that would be a lot harder I think. We look for the installed
libs using pkg-config. How would we do that for non-root builds?

Having one box (maybe a virtual machine?) that builds and installs all
the libs as packages would be very nice. Maybe even one VM for RPM and
one for DEB based systems? I don't think it's a good fit for the build
farm though, or at least not on our general purpose build farm boxes.

Cheers, Tridge