On Sat, 2008-02-02 at 18:15 +0100, Felix Martini wrote:

Magnus Therning wrote:

...

Is it possible to get Cabal to use 'cl' (Microsoft's C/C++ compiler shipped with Visual Studio Express)?

Duncan Coutts wrote:

...

The problem is to get GHC to use 'cl'. That's a longer term project that GHC HQ are interested in. There's something about it on the GHC dev wiki I think. Don't hold your breath.

When using the native code generator only foreign C code must be compiled with a C compiler. Presently Cabal passes C sources that are listed in the 'c-sources' field of a cabal file to GHC. It would be nice to have a Cabal field to specify the compiler for C sources, say 'c-sources-compiler: msvc'. The default would still be gcc, but with a Cabal flag the user would be able to change that to e.g. Sun's C compiler.

It would be reasonable to use the system C compiler rather than ghc, however we will have to do more work to find what extra include dirs get used and have Cabal pass those. Currently we pass the -package flags to ghc which ghc uses to look up what include dirs those packages add, and then it calls the C compiler with those extra include dirs. Cabal would have to do that itself. Duncan

On Sat, 2008-02-02 at 18:50 +0000, Magnus Therning wrote:

Duncan Coutts wrote: [..]

...

It would be reasonable to use the system C compiler rather than ghc, however we will have to do more work to find what extra include dirs get used and have Cabal pass those.

Currently we pass the -package flags to ghc which ghc uses to look up what include dirs those packages add, and then it calls the C compiler with those extra include dirs. Cabal would have to do that itself.

Well it sounds like I'll have to settle for a two-step build procedure for the time being. Luckily I managed to recall the existence of CMake just today, so it seems I can make my Haskell-hacking-on-Windows experience somewhat bearable...

Just so I'm sure I understand... So you're building a .dll using just C code and then you want to link that in with a Haskell prog that uses that .dll. And it is essential that the C code be built using MS's C compiler and not gcc. Is that right? And you'd like to have the .dll built using Cabal rather than having to hack an external C/Makefile. Or are you just trying to link some C code statically into a haskell program, but it just so happens that this C code relies on being built with MS's C compiler rather than gcc. Perhaps you could clarify what it is you're trying to do (the end goal, just just the minutia) so we can see what feature it is that Cabal is missing that would help your situation. When we figure that out we can file a feature request so it is not forgotten. Duncan

On Sat, 2008-02-02 at 22:33 +0000, Magnus Therning wrote:

Duncan Coutts wrote: [..]

...

Just so I'm sure I understand...

Sure thing.

...

Or are you just trying to link some C code statically into a haskell program, but it just so happens that this C code relies on being built with MS's C compiler rather than gcc.

Yes, this is exactly it. I mean, I could probably hack the incomplete mingw header files to add the functions I need, but I thought it'd be much easier to just use Microsoft's development environment.

...

Perhaps you could clarify what it is you're trying to do (the end goal, just just the minutia) so we can see what feature it is that Cabal is missing that would help your situation. When we figure that out we can file a feature request so it is not forgotten.

The end goal is to sneak Haskell into the work place ;-)

What I'd really like to see is the ability to “drive” development completely from Haskell. With that I mean to, just as on Linux, have a single cabal file that compiles the C code containing the wrappers while still having access to a complete development environment. On Windows that means compiling C/C++ with MS's tool set.

I hope that clarifies what goes on in my muddy mind a bit...

Ok, so you could create a separate component to produce the .dll / .a from the C code but you'd prefer the convenience of being able to just: c-sources: blah.c and have them included in the project, but built using the MS C compiler. So I think we should file a feature request about building C sources using gcc/ms-c directly rather than going via ghc as that would give us the flexibility to use alternative C compilers. Perhaps you'd like to file it, otherwise I can. http://hackage.haskell.org/trac/hackage/ Duncan

Hello Duncan, Sunday, February 3, 2008, 5:24:22 AM, you wrote:

Ok, so you could create a separate component to produce the .dll / .a from the C code but you'd prefer the convenience of being able to just: c-sources: blah.c and have them included in the project, but built using the MS C compiler.

So I think we should file a feature request about building C sources using gcc/ms-c directly rather than going via ghc as that would give us the flexibility to use alternative C compilers.

sorry, i think it's not whole story. gcc and msvc are probably incompatible in the meaning that you can't link together code produced by two compilers. exactly dll should be generated which allow to avoids this incompatibility -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com

Aaron Denney wrote:

On 2008-02-03, Bulat Ziganshin wrote:

...

Hello Duncan,

Sunday, February 3, 2008, 5:24:22 AM, you wrote:

...

Ok, so you could create a separate component to produce the .dll / .a from the C code but you'd prefer the convenience of being able to just: c-sources: blah.c and have them included in the project, but built using the MS C compiler. So I think we should file a feature request about building C sources using gcc/ms-c directly rather than going via ghc as that would give us the flexibility to use alternative C compilers. sorry, i think it's not whole story. gcc and msvc are probably incompatible in the meaning that you can't link together code produced by two compilers. exactly dll should be generated which allow to avoids this incompatibility

Well, the whole purpose of the ABI is to allow linking code together from different compilers. This doesn't mean there won't be any problems, but I'd expect the ones that crop up won't *strictly* be because of the compilers being different, but because of the C libraries being different. DLL vs object files shouldn't change things all that much.

Well, I can at least report that linking a library (.lib) produced using cl (via CMake) with object files created by GHC works well. I do get a warning: Warning: .drectve `/manifestdependency:"type='win32' name='Microsoft.VC90.CRT' version='9.0.21022.8' processorArchitecture='x86' publicKeyToken='1fc8b3b9a1e18e3b'" /DEFAULTLIB:"uuid.lib" /DEFAULTLIB:"uuid.lib" /DEFAULTLIB:"MSVCRT" /DEFAULTLIB:"OLDNAMES" ' unrecognized But it doesn't seem to have any impact on the resulting executable. /M -- Magnus Therning (OpenPGP: 0xAB4DFBA4) magnus＠therning．org Jabber: magnus．therning＠gmail．com http://therning.org/magnus What if I don't want to obey the laws? Do they throw me in jail with the other bad monads? -- Daveman