[PATCH] Auto-generate param_functions.c at build time

[Michael Adam]

Hi Andrew and Garming,

it is good to see that you are making progress on this!

Next step would be to generate the param_table right?
And then to not have mkparamdefs generate the headers
from the generated param_functions but have the script
generate_param.py generate them in one go. Correct?


I will try hard to find the time to look very closely
at the patches and the resulting code in the next days.

It is good to move towards a central place of definition of
conf parameters. But I do second Volker's request to not rush
the patchset into master, and let it ripe a bit in a private
tree, because it is very important that a few people understand
it properly... :-)

The last step, generating the headers from the FN macros
etc, had the positive effect to remove one (or so) place to
touch when adding a parameter, but for me at least the changes
done at that time had the negative effect that they made it
much more difficult to understand the loadparm code.
This is probably mainly related to the splitting between
s4- and s3-loadparm, and I hence think it is very important
to refactor the code to be able to share loadparm.
I would like to be assured that this goal (which I would have
loved to see reached before generating the code) is not made
much more difficult to achieve by the new autogeneration-changes.

Cheers - Michael


On 2014-01-15 at 02:22 +1300, Andrew Bartlett wrote:
> On Tue, 2014-01-14 at 18:15 +1300, Garming Sam wrote:
> > This is a patch that goes on top of the tree that Andrew Bartlett posted 
> > earlier.
> > 
> > Right now, the script only performs the generation for the 
> > param_functions.c file, however, it should eventually support generation 
> > of some of the other files dependent on it.
> > 
> > It also moves the final remaining special cases away from 
> > param_functions so they can be noted and dealt with appropriately.
> > 
> > As well as successfully building,  the output was sorted and compared 
> > with the original manually created file to check that it was consistent.
> > 
> 
> Thanks Garming,
> 
> One thing we need to fix up is the comment at the top of
> lib/param/loadparm.c and source3/param/loadparm.c:
> 
>  * To add a parameter:
>  *
>  * 1) add it to the global or service structure definition
>  * 2) add it to the parm_table
>  * 3) add it to the list of available functions (eg: using
> FN_GLOBAL_STRING())
>  * 4) If it's a global then initialise it in init_globals. If a local
>  *    (ie. service) parameter then initialise it in the sDefault
> structure
> 
> It needs to be something like:
> 
>  * To add a parameter:
>  *
>  * 1) add it to the XML documentation in docs-xml/smbdotconf
>  * 2) add it to the parm_table in lib/param/param_table.c
>  * 3) If it's a global then initialise it in init_globals. If a local
>  *    (ie. service) parameter then initialise it in the sDefault
> structure
> 
> The new way of adding an smb.conf parameter will be strange to some
> developers who haven't followed this closely, so we need to give them as
> many clues as possible.  Perhaps also put /* autogenerated from the XML
> documentation in docs-xml/smbdotconf by script/generate_param.py */ at
> the top of the generated files and just before the #include. 
> 
> 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
> 
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 215 bytes
Desc: Digital signature
URL: <http://lists.samba.org/pipermail/samba-technical/attachments/20140114/c24c05af/attachment.pgp>