running autogen-waf.sh as part of waf dist
idra at samba.org
Tue Apr 13 08:18:53 MDT 2010
On Tue, 2010-04-13 at 23:32 +1000, tridge at samba.org wrote:
> > I think we need to carefully consider how much this dependency
> > 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
> > 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.
Samba Team GPL Compliance Officer <simo at samba.org>
Principal Software Engineer at Red Hat, Inc. <simo at redhat.com>
More information about the samba-technical