On Mon, 2013-02-25 at 00:28 -0500, Dan Cross wrote:
>
> Why go to all that bother? Why not just write code that writes out
> the path you want to take and link against it?
>
{shrug} You could do that too.
I spent a decade doing work in Java-land, a language where by design we
*didn't* have #i
On Sun, Feb 24, 2013 at 5:28 PM, Andrew Cowie <
and...@operationaldynamics.com> wrote:
> On Sat, 2013-02-16 at 08:18 +0100, Henk-Jan van Tuyl wrote:
> > > Anyone have any idea if the Cabal library exposes this
> > > somewhere?
> >
> > See...
>
> I blogged about my solution using Krzysztof and Henk
On Sat, 2013-02-16 at 08:18 +0100, Henk-Jan van Tuyl wrote:
> > Anyone have any idea if the Cabal library exposes this
> > somewhere?
>
> See...
I blogged about my solution using Krzysztof and Henk's suggestions here:
http://blogs.operationaldynamics.com/andrew/software/haskell/config-dot-h-and-i
With apologies for prolonging a tangential topic, I'd like to
sharpen anti-ifdef comments that have been posted already.
1. An ifdef for portability is an admission of nonportability.
What it does is point out a nonportability--a useful crutch
for maintainers, but a crutch nonetheless.
2
As counterpoint to Vincent Hanquez' note about the certificate store
on MacOS & Windows, I'd like to cast some doubt on the notion that
you can reliably find the cert store here on Linux or the *BSDs.
So, if my experience with platforms like that is any guide, you'd
rather not "hard code" this val
> __WIN32__
use mingw32_HOST_OS
> __MACOSX__
darwin_HOST_OS
On Sat, 16 Feb 2013 01:05:13 +1100 Andrew Cowie
wrote:
> I've got a piece of code that looks like this:
>
> baselineContextSSL :: IO SSLContext
> baselineContextSSL = do
> ctx <- SSL.context
>
On Sat, 16 Feb 2013 01:57:14 +0100, Andrew Cowie
wrote:
Anyone have any idea if the Cabal library exposes this
somewhere?
See:
http://hackage.haskell.org/packages/archive/Cabal/1.16.0.3/doc/html/Distribution-System.html
Regards,
Henk-Jan van Tuyl
--
http://Van.Tuyl.eu/
http://members.che
On Fri, 2013-02-15 at 15:16 +0100, Krzysztof Skrzętnicki wrote:
> See:
> http://www.haskell.org/cabal/users-guide/developing-packages.html#configurations
That link says os():
"Tests if the current operating system is name. The argument is
tested against System.Info.os on the targ
On 02/15/2013 02:05 PM, Andrew Cowie wrote:
all very nice (this being necessary because apparently the non-free
operating systems don't store their certs in a reliably discoverable
place; bummer).
Sorry the answer is out of topic, but this is not true.
Windows certificate and macos X certifica
That's interesting. But are there standard values for those functions? I'm
guessing not, seeing a how they're String and not an ADT.
AfC
Sydney
Artyom Kazak wrote:
>You can know the OS and arch without even resorting to CPP; see
>System.Info which defines `os` and `arch`.
--
Andrew Fred
On Fri, Feb 15, 2013 at 9:05 AM, Andrew Cowie <
and...@operationaldynamics.com> wrote:
> I've got a piece of code that looks like this:
>
> baselineContextSSL :: IO SSLContext
> baselineContextSSL = do
> ctx <- SSL.context
> SSL.contextSetDefaultCiphers ctx
Well, for sure you can in define that in .cabal file:
if !os(windows)
CC-Options: "-DWINDOWS"
or something. See:
http://www.haskell.org/cabal/users-guide/developing-packages.html#configurations
On Fri, Feb 15, 2013 at 3:05 PM, Andrew Cowie <
and...@operationaldynamics.com> wrote:
>
Andrew Cowie писал(а) в своём письме Fri,
15 Feb 2013 17:05:13 +0300:
So my question is: what's an appropriate Haskell mechanism for building
code that is OS / arch / distro specific? It's not like I have autoconf
running generating me a config.h I could #include, right?
You can know the O
I've got a piece of code that looks like this:
baselineContextSSL :: IO SSLContext
baselineContextSSL = do
ctx <- SSL.context
SSL.contextSetDefaultCiphers ctx
#if defined __MACOSX__
SSL.contextSetVerificationMode ctx SSL.VerifyNone
14 matches
Mail list logo
