running as part of waf dist

simo idra at
Tue Apr 13 08:18:53 MDT 2010

On Tue, 2010-04-13 at 23:32 +1000, tridge at wrote:
>  > 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?

No, just the python dependency.

>  > > 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.

No, what I am saying is that I find it ok to use the waf build for ldb
in the buildfarm, this way we can see how it works there.

>  > 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?

I think you can set the PKG_CONFIG_PATH environment variable to tell
pkg-config where to look for an alternate place to find .pc files, but I
have not tried it.

> 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.

I think I can provide a VM, but if the env variable is sufficient I
would try that one first.


Simo Sorce
Samba Team GPL Compliance Officer <simo at>
Principal Software Engineer at Red Hat, Inc. <simo at>

More information about the samba-technical mailing list