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

[Martin Schwenke]

On Thu, 26 Feb 2015 22:28:32 +1300, Andrew Bartlett
<abartlet at samba.org> wrote:

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

True...  but it was the best word I could think of at the time...  :-)

I want the best of all possible worlds.  I want to be able to build
CTDB against Samba's utility code but I don't want to have to build all
of it, especially because some of that utility code drags in other
subsystems and libraries that aren't needed.  At the moment I can build
CTDB in much less than a minute, which is helpful when reorganising
patches and things like that...

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

That sounds like a good idea.  I don't know how to do that
automatically.

I seem to recall that the main problem with subsystems is that if
multiple libraries depend on them then their symbols get included in
multiple libraries.  One of the developer build checks rightly gets
upset when this happens...

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

True.  I'll look at doing that.  This might touch lot of code since, for
example, lib/util/debug.h would move to lib/util/core/debug.h.

I have a whole bunch of lib/util cleanups sitting in a mess in a
branch.  I'd like to get back to it one day when time allows. However,
we do need an overall strategy... and "let external users feel the
pain", as suggested elsewhere, is probably the most realistic...  :-)

peace & happiness,
martin