<div dir="ltr"><div class="gmail_extra">On Fri, Feb 15, 2013 at 9:05 AM, Andrew Cowie <span dir="ltr"><<a href="mailto:andrew@operationaldynamics.com" target="_blank">andrew@operationaldynamics.com</a>></span> wrote:<br>
<div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">I've got a piece of code that looks like this:<br>
<br>
baselineContextSSL :: IO SSLContext<br>
baselineContextSSL = do<br>
ctx <- SSL.context<br>
SSL.contextSetDefaultCiphers ctx<br>
#if defined __MACOSX__<br>
SSL.contextSetVerificationMode ctx SSL.VerifyNone<br>
#elif defined __WIN32__<br>
SSL.contextSetVerificationMode ctx SSL.VerifyNone<br>
#else<br>
SSL.contextSetCADirectory ctx "/etc/ssl/certs"<br>
SSL.contextSetVerificationMode ctx $<br>
SSL.VerifyPeer True True Nothing<br>
#endif<br>
return ctx<br>
<br>
all very nice (this being necessary because apparently the non-free<br>
operating systems don't store their certs in a reliably discoverable<br>
place; bummer).<br>
<br>
That, however, is not the problem. After all, this sort of thing is what<br>
#ifdefs are for. The problem is needing to get an appropriate symbol<br>
based on what OS you're using defined.<br>
<br>
I naively assumed there would be __LINUX__ and __MACOSX__ and __WIN32__<br>
defined by GHC because, well, that's just the sort of wishful thinking<br>
that powers the universe.<br>
<br>
So my question is: what's an appropriate Haskell mechanism for building<br>
code that is OS / arch / distro specific? It's not like I have autoconf<br>
running generating me a config.h I could #include, right?<br>
<br>
This feels simple and an appropriate use of CPP; even the symbol names<br>
look just about like what I would have expected; stackoverflow said so,<br>
must be true. Just need to get the right symbol defined at build time.<br>
<br>
Any suggestions?</blockquote><div><br></div><div style>Things like this have been the bane of Unix programmers for decades; the C pre-processor has always been kind of a hack, mostly because of things like #ifdef and the huge messes they create. For more on why this is so bad from the Unix side of the house, see: <a href="http://static.usenix.org/publications/library/proceedings/sa92/spencer.pdf">http://static.usenix.org/publications/library/proceedings/sa92/spencer.pdf</a></div>
<div style><br></div><div style>A better solution is to define a standard interface called by your code and a per-system module that implements that interface and does the things you need, then simply include one for the appropriate system at compile time. E.g., a Darwin and Win32 modules that provide a function that calls 'SSL.contextSetVerificationMode ctx SSL.VerifyNone', and some kind of Generic module that provides a function that does the rest.</div>
<div style><br></div><div style> - Dan C.</div><div style><br></div><div style><br></div></div></div></div>