<div dir="ltr"><br><div class="gmail_extra"><div class="gmail_quote">On Thu, Jun 13, 2013 at 4:12 AM, 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">I have been porting some of my custom modifications to app_meetme from 1.2 to<br>
Asterisk 11 (yes, I know about ConfBridge - that's for later 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 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><span class="HOEnZb"><font color="#888888"><br></font></span></blockquote><div><br></div><div style>Alas, that is the case.</div><div style><br></div><div style>In general, we've taken the approach to use compile time options as little as possible. We try hard to relegate their usage only to cases that prevent compilation issues when module dependencies aren't present. I'd speculate that a patch that proposed an application parameter that was optionally included at compile time would most likely not be accepted for inclusion in mainline Asterisk. Hence, this idea is not something we built into the XML documentation generation - we've never had a use case for it.</div>
<div style><br></div><div style>A few possible options:</div><div style><br></div><div style>The first would be to not have application options be determined at compile time.</div><div style><br></div><div style>The second would be to modify the XML parser in xmldoc.c to pass over elements if an attribute is present on the XML element. It would be an additional step to 'include' the documentation if you choose to compile Asterisk; however it would at least give you the ability to toggle on/off a particular element.</div>
<div style><br></div><div style>Another option would be to have a script that updates the produced doc-en_US.xml file with the documentation if someone has enabled the build option. The script could read in the XML DOM, update the contents, and re-write the file. Asterisk determines the documentation by reading this file on startup, so you can manipulate it outside of the source and the build process.</div>
<div style><br></div><div style>Matt</div></div><div><br></div>-- <br><div dir="ltr"><div>Matthew Jordan<br></div><div>Digium, Inc. | Engineering Manager</div><div>445 Jan Davis Drive NW - Huntsville, AL 35806 - USA</div>
<div>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></div></div>
</div></div>