Building VFS modules out of tree

[Andrew Bartlett]

On Mon, 2014-03-31 at 12:55 -0700, Richard Sharpe wrote:
> On Mon, Mar 31, 2014 at 10:51 AM, Jeremy Allison <jra at samba.org> wrote:
> > On Mon, Mar 31, 2014 at 10:43:27AM -0700, Richard Sharpe wrote:
> >> On Sun, Mar 30, 2014 at 8:39 PM, Andrew Bartlett <abartlet at samba.org> wrote:
> >> > On Sun, 2014-03-30 at 19:26 -0700, Richard Sharpe wrote:
> >> >> On Sun, Mar 30, 2014 at 6:42 PM, Andrew Bartlett <abartlet at samba.org> wrote:
> >> >> > On Sun, 2014-03-30 at 16:48 -0700, Richard Sharpe wrote:
> >> >>
> >> >> [Some stuff deleted]
> >> >>
> >> >> >> The question then is, for those people who have their own VFS modules
> >> >> >> and do not want to place them in the Samba source tree, how do they
> >> >> >> build with waf? How to the gain access to all the configuration stuff
> >> >> >> and so forth.
> >> >> >
> >> >> > I think you would have to patch them or at least the reference to them
> >> >> > in a matching Samba source tree.
> >> >>
> >> >> This is a very much less than ideal situation for many OEMs it seems to me.
> >> >>
> >> >> Something that worked very well with Samba 3.5. and 3.6 is that OEMs
> >> >> who only needed a VFS module or two could use RPMs or other packages
> >> >> supplied by RedHat, Debian, SuSE, etc, and could then add their VFS
> >> >> module as a separate RPM and could build their VFS module without
> >> >> modifying the Samba source tree for the main package.
> >> >
> >> > How did they do that?  As I see it, they would have needed a built
> >> > source tree to get the config.h file that was used, and the full source
> >> > to get at the headers, because we have never published them as public
> >> > headers.
> >>
> >> You are correct. Samba is the most difficult open source package out
> >> there. People using it routinely have to jump through about 40 hoops
> >> and do one hundred back flips to use it. As such that makes my skills
> >> worth a lot.
> >
> > Ouch, that's a painful comment from someone who knows :-(.
> >
> > Richard, how can we fix this ?
> 
> I need to think about that. I need to learn more about WAF because I
> think it is a done deal.
> 
> However, the problem is that while autoconf etc are hard, there are
> likely 10,000 people worldwide who know how to deal with it. For WAF
> there are about 10 people worldwide who know about it :-)

I don't think this is about WAF or autoconf.  If we genuinely want
external folks to be able to build modules for this, we need to publish
everything as a public header file and library to link to, then watch
for changes with the same ABI tracking we use elsewhere. 

Then users can build against those using whatever tools they choose,
just as waf isn't needed to link against ldb, or libsmbclient. 

The difficulty is as seen in the attempts to allow building of external
passdb modules, where you see great difficultly in defining how much of
the internals of Samba need to be in the ABI for external passdb
modules.  That is even before we start to touch on ensuring that the
elements in the ABI are consistently represented without reference to
our configure tests and config.h.

A perhaps better example is the rpc server modules for source4 (those
exposed for openchange), but even there we expose much, much more of our
internals then I would care to repeat.

In short, this is difficult, and I would be careful what you wish for.
If we did define an ABI here that isn't "includes.h", then many of the
internal but helpful functions external modules might use wouldn't be in
it! 

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