On Wed, 30 Nov 2016, mosto...@gmail.com wrote:

Probably a stupid idea...will it make sense that information being populated from rsysloc-doc? (or viceversa, like javadoc)

Since this is the code that creates parameter and variable names in the modules, I don't see how the -doc project could push it into the source

I'm thinking that rsyslog-doc would create these files from the rsyslog source (or that the rsyslog source would output the data to be picked up by the doc process)

Having everything on one place looks great to me

the question is how.

Part of this comes down to nuances in C that I don't know. If we add two string pointers to the array, can we declare the array with constants and have the compiler store the constants somewhere and create the appropriate pointers to them

Is there some standard tool that can generate docs from C source? I think I've seen people talk about sphinx (or something similar), but I've never followed things very closely, and I don't have any idea if it can deal with things in an array.


And then there is the problem of backwards compatibility. Is there a way to make this change a module at a time? or do we have to change all of rsyslog (and break any out-of-tree modules) in a single step?

David Lang



El 28/11/16 a las 17:50, David Lang escribió:
we have a few cases where the documentation doesn't match the module parameters (wrong action parameters shown). While we can go through and fix the ones that we find as we find them, I think we should look at finding a way to make this more automated

Is there a reasonable way to expand the array that defines the v6 parameters, which currently defined as:

/* the following defines describe the parameter block for puling
 * config parameters. Note that the focus is on ease and saveness of
 * use, not performance. For example, we address parameters by name
 * instead of index, because the former is less error-prone. The (severe)
 * performance hit does not matter, as it is a one-time hit during config
 * load but never during actual processing. So there is really no reason
 * to care.
 */
struct cnfparamdescr { /* first the param description */
        const char *name;/**< not a es_str_t to ease definition in code */
        ecslCmdHdrlType type;
        unsigned flags;
};

to contain the default value and a description.

Then if we can add a module general description field, we should have the ability to create allmost all of the module documenation pages automatically (except for the legacy config stuff, and that could be either added as another variable in the module, or maintained outside of the module)

Thoughts?

David Lang
_______________________________________________
rsyslog mailing list
http://lists.adiscon.net/mailman/listinfo/rsyslog
http://www.rsyslog.com/professional-services/
What's up with rsyslog? Follow https://twitter.com/rgerhards
NOTE WELL: This is a PUBLIC mailing list, posts are ARCHIVED by a myriad of sites beyond our control. PLEASE UNSUBSCRIBE and DO NOT POST if you DON'T LIKE THAT.

_______________________________________________
rsyslog mailing list
http://lists.adiscon.net/mailman/listinfo/rsyslog
http://www.rsyslog.com/professional-services/
What's up with rsyslog? Follow https://twitter.com/rgerhards
NOTE WELL: This is a PUBLIC mailing list, posts are ARCHIVED by a myriad of sites beyond our control. PLEASE UNSUBSCRIBE and DO NOT POST if you DON'T LIKE THAT.
_______________________________________________
rsyslog mailing list
http://lists.adiscon.net/mailman/listinfo/rsyslog
http://www.rsyslog.com/professional-services/
What's up with rsyslog? Follow https://twitter.com/rgerhards
NOTE WELL: This is a PUBLIC mailing list, posts are ARCHIVED by a myriad of 
sites beyond our control. PLEASE UNSUBSCRIBE and DO NOT POST if you DON'T LIKE 
THAT.

Reply via email to