[PATCH] lib/util: Build iov_buf library only when building samba

[Andrew Bartlett]

On Thu, 2015-02-26 at 19:57 +1100, Martin Schwenke wrote:
> On Thu, 26 Feb 2015 21:40:59 +1300, Andrew Bartlett
> <abartlet at samba.org> wrote:
> 
> > On Thu, 2015-02-26 at 11:52 +1100, Amitay Isaacs wrote:
> 
> > > Adding new libraries in lib/util at the wrong place in wscript breaks
> > > standalone ctdb rpm build.
> > > 
> > > Here's a patch to fix this.
> > > 
> > > Please review and push if ok.
> 
> > We really need to have an autobuild rule for major build modes like this
> > (major in the sense of most of the common build roles, as compared with
> > the minor modes arising from every possible build combination). 
> > 
> > That is why we do a build with all bundled libraries, and then one where
> > we build all the libraries as system libs, and link against them.
> > Perhaps you are just missing ctdb from that samba-libs rule?
> 
> Autobuild does do a standalone CTDB build and runs the CTDB test
> suite.
> 
> This problem was a bit subtler, so it would be hard to try to catch in
> autobuild. During a CTDB RPM build the new private library was built and
> installed, and then it fell over at the last hurdle due to an
> unpackaged file (libiov-buf-ctdb.so, I think).  Testing that in
> autobuild is probably over the top.

> Unless someone thinks I'm crazy (in this particular respect ;-) then
> I'll do that tomorrow...

I think this particular issue is 'not a bug' in Samba.  I do draw the
line at not breaking packaging scripts.  The reason I say that is these
tend to assert on the exact form of the build product, yet we can, do
and will continue to re-organise our internal libraries, and so I think
packaging just needs to cope reactively. 

For example, we recently renamed all our libraries, and I'm sure that
caused quite some churn, but I don't apologise for that. 

We also will continue to add new code to lib/util, some of it nice and
self-contained like this one.  The fact that ctdb does or does not use a
particular bit of code it is not a good criteria for a label of 'core'. 

A better approach to the installation of not-yet-in-use private libs
would be to have the make install determine that they are not linked to,
or when build deps permit, to avoid their proliferation by making them
subsystems and put them into a more reasonable grouping library. 

Finally, while I appreciate you not wishing to churn nor link to the
whole codebase, if you have found a part of lib/util that isn't
dependent on other parts, then the correct approach isn't to have the
lib/util wscript file split up with an if, but to have a lib/util/core
and have waf in ctdb point only to that. 

Thanks,

Andrew Bartlett

-- 
Andrew Bartlett                       http://samba.org/~abartlet/
Authentication Developer, Samba Team  http://samba.org
Samba Developer, Catalyst IT          http://catalyst.net.nz/services/samba


-- 
Andrew Bartlett                       http://samba.org/~abartlet/
Authentication Developer, Samba Team  http://samba.org
Samba Developer, Catalyst IT          http://catalyst.net.nz/services/samba