<div dir="ltr"><span class=""></span><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="">>> Drop the includes altogether, and forward declare the needed symbols.<br></span></blockquote><div><br>But then you end up with forward declarations of symbols that may not even exist.<br><br> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="">
> Why not use the configure.ac-based approach suggested by Chuck?</span> </blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="">
><br>
</span>Few reasons come to mind:<br>
<br>
Not to mention that every user will need a check analogous to the one<br>
in <a href="http://configure.ac" rel="noreferrer" target="_blank">configure.ac</a>.<br></blockquote><div><br></div><div>There's already extra -D requirements that get pushed into the generated .pc files.  It will get populated by the @GL_PC_CFLAGS@ configure variable.  A consumer wouldn't need to know how to check for GLX enablement, just use the flags they're given.<br></div><div> <br></div></div>I don't particularly like arbitrarily adding -D flags either though so I get where you're coming from.  Typically these sorts of things would get pushed into a <a href="http://config.h.in">config.h.in</a> generated at configure time and installed with the rest of the headers but it seems silly to do add a conf header like that when there's not one already for just this change.<br></div></div>