common lpcfg_ as a shim to allow greater code sharing

[Andrew Bartlett]

On Tue, 2011-10-11 at 23:33 +0200, Michael Adam wrote:
> Hi Andrew,
> 
> thanks for proposing your patches here.
> I did not yet manage to look at them thoroughtly
> (hope to find the time in the next couple of
> days), but a couple comments up front:
> 
> Andrew Bartlett wrote:
> > Metze, Michael
> > 
> > At SDC I spoke about my idea to move the source4 loadparm code into
> > 'common', so as to allow common code to be written against the lpcfg_*()
> > functions.  In turn, these calls can be directed to either loadparm
> > system by calling loadparm_init() or loadparm_init_s3() as appropriate.
> 
> Yeah. Without knowing the details yet, I don't like the idea of
> moving the s4 lp code to common as a start, as you will remember
> from our discussion at the sdc. My ideal procedure would be to
> change the s3 and s4 loadparm code until the common pieces are
> identical and can be moved to common. I also have a couple of
> more concrete ideas for steps into that direction. But
> practically, I will probably not find the time to complete this very
> soon. So I will look at your proposed patches and also see to what
> extent I can still implement my ideas on top of that. :-)

As we have both found out, working to merge loadparm takes a lot longer
than it would ever appear at first.  Even with the best of will and the
most generous allocation of time, I can't see us having a completely
common loadparm in the near future.  In particular, the challenges of
the % subs in the s3 loadparm code make achieving this in full quite
difficult.  

(That said, I did find about 3 functions that we could merge, and we can
merge the enum value lists.  I'll propose those in due course. )

Additionally, there is a new challenge created by the combined build in
attempting to merge code into two identical copies, that is that we now
must ensure there are no duplicate symbols across the entire combined
build. 

Given all this, I'm resigned to a medium term where we have both
loadparm systems, with one wrapping the other where required. 

> > I've prepared a branch with my patch proposal.  It does not include the
> > changes to the autoconf build system, because I only wish to change that
> > once I have a real-world user for that code, and this has taken a little
> > longer to prepare than I expected.
> 
> No problem with that.
> 
> > I also wish to address Volker's concern about the build-time
> > perl dependency before I make any further changes to the
> > autoconf build.
> 
> Er, that sounds nice, but what was this?

Volker mailed the list at SDC to complain that the autoconf based build
now requires perl at build time, not just at ./autogen.sh time.  To meet
this desire, we will either need a 'make dist' target (as part of the
release packaging) or to put essentially a mini-makefile in the
autogen.sh covering the generated files.  (Or decide that perl at build
time is a reasonable requirement).

> > The changes are in this branch:
> > http://git.samba.org/?p=abartlet/samba.git/.git;a=shortlog;h=refs/heads/common-lpcfg-shim
> > 
> > As I make clear in the commit, this is not an attempt to define once and
> > for all a common loadparm.  This is just a move of the files, and the
> > minimum work required to enable to result to compile in both build
> > systems.  The power of the loadparm_init_s3() shim is shown well by the
> > new vfs_dfs_samba4 module, and I want to enable other code to use this
> > feature while we continue the slow merge task.  
> 
> Sounds reasonable so far. 

Thanks.

> But I would appreciate if you gave me a
> couple of more days to review.

I can certainly give you more time in future, particularly as we move to
any substantive patches that impact on the source3 loadparm.  I took the
step to handle the rename of the s4 loadparm code because I wanted to
get the 'rename and fix clear compile issues' step out of the way,
before others need to make changes (ie, adding a parameter), and to
reduce the patches I keep outstanding to just those that actually make a
difference to behaviour (ie, using it).

I'm quite open to further suggestions from here - the reason I mailed
you and the list in advance was to give you a heads-up so you would know
where I was working and the direction I was hoping to go from here.

We have a lot of work ahead of us to try and merge and build subsystems
that use the loadparm code, and I hope this is one small step towards
having the loadparm systems work together, even if as I fear we cannot
actually get the loadparm systems themselves merged. 

Thanks,

Andrew Bartlett

-- 
Andrew Bartlett                                http://samba.org/~abartlet/
Authentication Developer, Samba Team           http://samba.org