[Asterisk-Dev] generation of config files from source code ?

[Kaloyan Kovachev]

 Having the config in the (right place in the) source file would also help to
find the option easier and to check what's going on and where it starts, but
there should be also a way to control the right location of _this_ 'comment
line' in the config file itself.
 The order of appearance of the lines in the config file and in the source
file is usually different, which could make a bigger mess instead of helping
to keep them in sync, I think

On Sun, 20 Nov 2005 13:43:15 -0800, Luigi Rizzo wrote
> On Sun, Nov 20, 2005 at 12:47:44PM -0600, Tilghman Lesher wrote:
> > On Sunday 20 November 2005 03:42, Luigi Rizzo wrote:
> > > How about this to keep sample config files in sync with the source
> > > code:
> > >
> > > put the example config file for a channel/module/whatever embedded
> > > in a comment in the source code (much like what is in
> > > channels/chan_oss.c) and put in the configs/ directory a Makefile
> > > and a small awk script to generate the sample from the source file.
> > 
> > I think I understand what you're trying to do, but I also think this
> > is the wrong approach.  We certainly need to keep the config files in
> > sync with the source, so we don't have undocumented configuration
> > options.  That's best done with a policy directive that whenever you
> > add or change an option, you must also update the configuration file.
> > 
> > Keeping the configuration file inline with the source doesn't actually
> > solve the problem -- it merely moves the problem to a different
> > source file.  Keeping the configuration inline with the source may
> 
> the goal is make life easier to people -- both for
> the lazy programmer and for the police officer doing the code review.
> 
> If you change or fix or add an option and see the description
> 10-20 lines above, you as a lazy programmer are a lot more likely to 
> fix the documentation as well, and your reviewer will need a lot 
> less time to verify consistency rather than having to go look at a 
> different file.
> 
> Basically that's the reason why we have doxygen and other documentation
> generation tools and why they are used in asterisk as well.
> 
> I am really not inventing anything new here, just applying a 
> principle that was already used in the project...
> 
> 	cheers
> 	luigi
> _______________________________________________
> Asterisk-Dev mailing list
> Asterisk-Dev at lists.digium.com
> http://lists.digium.com/mailman/listinfo/asterisk-dev
> To UNSUBSCRIBE or update options visit:
>    http://lists.digium.com/mailman/listinfo/asterisk-dev