Using of C constants in Haskell sources; Determining compilation environment (Unix vs Windows)

Bulat Ziganshin

11 Jul 2006 11 Jul '06

11:28 a.m.

Hello Haskell, what is a best way to bring C constant (defined in header file) into the Haskell source? Haskell project is cabalized and should work with both Win and Unix while the constants are OS-specific. the best way i found at this moment is to use the following scheme: mmap.h: #if defined(mingw32_HOST_OS) || defined(__MINGW32__) || defined(_MSC_VER) .... #else INLINE int const_MAP_FILE( void ) { return MAP_FILE; } #endif mmap.hs: #if defined(mingw32_HOST_OS) || defined(__MINGW32__) || defined(_MSC_VER) .... #else foreign import ccall unsafe "mydefs.h const_MAP_FILE" mAP_FILE :: CInt #endif Second question is how to test whether program compiles under Unix or Windows environment. Posix/Win32 packages availability would be the best criterion but it can't be tested :( -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com

Show replies by date

Max Vasin

11 Jul 11 Jul

12:53 p.m.

...

...
...
...
...
"Bulat" == Bulat Ziganshin writes:

Bulat> Hello Haskell, what is a best way to bring C constant (defined Bulat> in header file) into the Haskell source? Haskell project is Bulat> cabalized and should work with both Win and Unix while the Bulat> constants are OS-specific. the best way i found at this moment Bulat> is to use the following scheme: Bulat> mmap.h: Bulat> #if defined(mingw32_HOST_OS) || defined(__MINGW32__) || Bulat> defined(_MSC_VER) .... #else INLINE int const_MAP_FILE( void ) Bulat> { return MAP_FILE; Bulat> } Bulat> #endif Bulat> mmap.hs: Bulat> #if defined(mingw32_HOST_OS) || defined(__MINGW32__) || Bulat> defined(_MSC_VER) .... #else foreign import ccall unsafe Bulat> "mydefs.h const_MAP_FILE" mAP_FILE :: CInt #endif Well, the haskell source is processed with cpp, so if constants are #define'd (and not declared with `const') you can use preprocessor macros to generate Haskell code (yeh, I know it's silly, but why not?). -- WBR, Max Vasin. NP: Nothing playing right now

Jeremy Shaw

2:47 p.m.

At Tue, 11 Jul 2006 19:28:13 +0400, Bulat Ziganshin wrote:

...

Hello Haskell,

what is a best way to bring C constant (defined in header file) into the Haskell source?

If this ^^^^^^^ was your entire question, I would say, use hsc2hs. http://haskell.org/ghc/docs/latest/html/users_guide/hsc2hs.html Maybe that is still a valid answer for your entire question? j.

Bulat Ziganshin

12 Jul 12 Jul

8:08 a.m.

New subject: Re[2]: Using of C constants in Haskell sources; Determining compilation environment (Unix vs Windows)

Hello Jeremy, Tuesday, July 11, 2006, 10:47:09 PM, you wrote:

...

...
what is a best way to bring C constant (defined in header file) into the Haskell source?

...

If this ^^^^^^^ was your entire question, I would say, use hsc2hs.

...

http://haskell.org/ghc/docs/latest/html/users_guide/hsc2hs.html

...

Maybe that is still a valid answer for your entire question?

I believe that it the simplest way for programmer. But is that the best way for users? i want to make building/installation as simple as possible using Cabal infrastructure. is it possible that some box will have Cabal, but not hsc2hs installed? -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com

Jeremy Shaw

2:06 p.m.

New subject: Re[2]: Using of C constants in Haskell sources; Determining compilation environment (Unix vs Windows)

At Wed, 12 Jul 2006 16:08:02 +0400, Bulat Ziganshin wrote:

...

I believe that it the simplest way for programmer. But is that the best way for users? i want to make building/installation as simple as possible using Cabal infrastructure. is it possible that some box will have Cabal, but not hsc2hs installed?

I would *guess* that hsc2hs is always distributed with ghc. I know it is on Linux and BSD -- I am not sure about Windows. If you build ghc from source, I believe it is automatically built and installed. If you want to support hugs as well, then they would need hschs-hugs installed. Debian includes that with hugs by default -- not sure about anyone else. j. ps. Also, if it matters, cpphs is typically *not* available by default (but cpp probably is).

Neil Mitchell

2:33 p.m.

New subject: Re[2]: Using of C constants in Haskell sources; Determining compilation environment (Unix vs Windows)

...

I would *guess* that hsc2hs is always distributed with ghc. I know it is on Linux and BSD -- I am not sure about Windows. It is.

...

If you want to support hugs as well, then they would need hschs-hugs installed. Debian includes that with hugs by default -- not sure about anyone else. Windows certainly does, I think its in the standard Hugs make scripts.

Hugs always has cpphs available, but doesn't provide a cpp. GHC doesn't ship with cpphs, probably for license reasons. However cpphs can be used used to simulate cpp on Unix (using cpphs.compat) and hopefully soon on Windows with a --cpp flag (although not yet). Cabal should take care of cpp on all platforms by using the distributed one though. Thanks Neil

John Meacham

13 Jul 13 Jul

7:07 p.m.

On Wed, Jul 12, 2006 at 04:08:02PM +0400, Bulat Ziganshin wrote:

...

I believe that it the simplest way for programmer. But is that the best way for users? i want to make building/installation as simple as possible using Cabal infrastructure. is it possible that some box will have Cabal, but not hsc2hs installed?

hsc2hs should always be installed. it is absolutly needed to write portable libraries because you can't hard-code c constants or types in your files and expect them to compile on different systems. it would be nice if these compiler independent tools hsc2hs, runhaskell, cabal-install could be split off into their own project independent of any particular compiler. John -- John Meacham - ⑆repetae.net⑆john⑈

6887

Age (days ago)

6889

Last active (days ago)

List overview

Download

6 comments

5 participants

participants (5)

Bulat Ziganshin
Jeremy Shaw
John Meacham
Max Vasin
Neil Mitchell