<div dir="ltr"><div><div class="gmail_extra"><div class="gmail_quote">On Thu, Jun 13, 2013 at 12:31 PM, Tony Mountifield <span dir="ltr"><<a href="mailto:tony@softins.co.uk" target="_blank">tony@softins.co.uk</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Matt, thanks for the reply and the ideas. I'll give them some thought.<br>
<br>
Another idea I had was to pass the .c file through cpp when extracting<br>
the XML. I haven't yet studied what happens in the Makefile to see<br>
whether this is a possibility.<br>
<br>
Cheers<br>
Tony<br></blockquote></div></div><br></div>Please note that the documentation in the .c file is in a C comment so preprocessing<br>will not work.<br><br>Richard<br><br></div><div class="gmail_extra"><br><br><div class="gmail_quote">
On Thu, Jun 13, 2013 at 12:31 PM, Tony Mountifield <span dir="ltr"><<a href="mailto:tony@softins.co.uk" target="_blank">tony@softins.co.uk</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Matt, thanks for the reply and the ideas. I'll give them some thought.<br>
<br>
Another idea I had was to pass the .c file through cpp when extracting<br>
the XML. I haven't yet studied what happens in the Makefile to see<br>
whether this is a possibility.<br>
<br>
Cheers<br>
Tony<br>
<br>
In article <<a href="mailto:CAN2PU%2B7VOoM790m69ouHNG6FOY057U00gC%2BfUAVxR15DAvvSYQ@mail.gmail.com">CAN2PU+7VOoM790m69ouHNG6FOY057U00gC+fUAVxR15DAvvSYQ@mail.gmail.com</a>>,<br>
<div class="HOEnZb"><div class="h5">Matthew Jordan <<a href="mailto:mjordan@digium.com">mjordan@digium.com</a>> wrote:<br>
> On Thu, Jun 13, 2013 at 4:12 AM, Tony Mountifield <<a href="mailto:tony@softins.co.uk">tony@softins.co.uk</a>>wrote:<br>
><br>
> > I have been porting some of my custom modifications to app_meetme from 1.2<br>
> > to<br>
> > Asterisk 11 (yes, I know about ConfBridge - that's for later<br>
> > investigation).<br>
> ><br>
> > I have some of my modifications conditionally included using #ifdef.<br>
> ><br>
> > In 1.2, I could use #ifdef conditions to control the contents of the<br>
> > application help in static const char *descrip, like this:<br>
> ><br>
> > static const char *descrip =<br>
> > " MeetMe([confno][,[options][,pin]]): Enters the user into a specified<br>
> > MeetMe conference.\n"<br>
> > .......<br>
> > " 'F' -- Pass DTMF through the conference.\n"<br>
> > #ifdef LOCKHOLD<br>
> > " 'h' -- Locked conference keeps user on hold instead of exiting.\n"<br>
> > #endif<br>
> > " 'i' -- announce user join/leave\n"<br>
> > .......<br>
> ><br>
> > However, in Asterisk 11, it appears that the application help is generated<br>
> > from the XML in the DOCUMENTATION comments. Putting #ifdef within that does<br>
> > not seem to have any effect. Everything gets included.<br>
> ><br>
> > So my question is, how can I make conditional variations in the application<br>
> > help that is compiled?<br>
> ><br>
> > I'm really hoping that the answer isn't just a blunt "you can't"...<br>
> ><br>
> Alas, that is the case.<br>
><br>
> In general, we've taken the approach to use compile time options as little<br>
> as possible. We try hard to relegate their usage only to cases that prevent<br>
> compilation issues when module dependencies aren't present. I'd speculate<br>
> that a patch that proposed an application parameter that was optionally<br>
> included at compile time would most likely not be accepted for inclusion in<br>
> mainline Asterisk. Hence, this idea is not something we built into the XML<br>
> documentation generation - we've never had a use case for it.<br>
><br>
> A few possible options:<br>
><br>
> The first would be to not have application options be determined at compile<br>
> time.<br>
><br>
> The second would be to modify the XML parser in xmldoc.c to pass over<br>
> elements if an attribute is present on the XML element. It would be an<br>
> additional step to 'include' the documentation if you choose to compile<br>
> Asterisk; however it would at least give you the ability to toggle on/off a<br>
> particular element.<br>
><br>
> Another option would be to have a script that updates the produced<br>
> doc-en_US.xml file with the documentation if someone has enabled the build<br>
> option. The script could read in the XML DOM, update the contents, and<br>
> re-write the file. Asterisk determines the documentation by reading this<br>
> file on startup, so you can manipulate it outside of the source and the<br>
> build process.<br>
><br>
> Matt<br>
><br>
> --<br>
> Matthew Jordan<br>
> Digium, Inc. | Engineering Manager<br>
> 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA<br>
> Check us out at: <a href="http://digium.com" target="_blank">http://digium.com</a> & <a href="http://asterisk.org" target="_blank">http://asterisk.org</a><br>
</div></div><div class="HOEnZb"><div class="h5">--<br>
Tony Mountifield<br>
Work: <a href="mailto:tony@softins.co.uk">tony@softins.co.uk</a> - <a href="http://www.softins.co.uk" target="_blank">http://www.softins.co.uk</a><br>
Play: <a href="mailto:tony@mountifield.org">tony@mountifield.org</a> - <a href="http://tony.mountifield.org" target="_blank">http://tony.mountifield.org</a><br>
<br>
--<br>
_____________________________________________________________________<br>
-- Bandwidth and Colocation Provided by <a href="http://www.api-digital.com" target="_blank">http://www.api-digital.com</a> --<br>
<br>
asterisk-dev mailing list<br>
To UNSUBSCRIBE or update options visit:<br>
<a href="http://lists.digium.com/mailman/listinfo/asterisk-dev" target="_blank">http://lists.digium.com/mailman/listinfo/asterisk-dev</a><br>
</div></div></blockquote></div><br></div>