Cabal + WinHugs + Windows + No C Compiler
Hi, I want to shove Hoogle's databases in to the appropriate Path's place, as Cabal tells me. However, I also want to develop Hoogle using WinHugs on Windows on a computer without a C compiler, and it seems that the generated Paths_Hoogle module requires FFI on Windows? Is there any way round this, or am I just out of luck in using Cabal's path feature in this situation? Thanks Neil
On Tue, 2006-11-07 at 18:08 +0000, Neil Mitchell wrote:
Hi,
I want to shove Hoogle's databases in to the appropriate Path's place, as Cabal tells me.
However, I also want to develop Hoogle using WinHugs on Windows on a computer without a C compiler, and it seems that the generated Paths_Hoogle module requires FFI on Windows? Is there any way round this, or am I just out of luck in using Cabal's path feature in this situation?
Perhaps it could call things from the System.Win32 lib instead of doing the FFI directly. Could you investigate what external functions we need exactly and if they're exported from System.Win32. I'll gladly accept a patch to do this. Duncan
Hi
However, I also want to develop Hoogle using WinHugs on Windows on a computer without a C compiler, and it seems that the generated Paths_Hoogle module requires FFI on Windows? Is there any way round this, or am I just out of luck in using Cabal's path feature in this situation?
Perhaps it could call things from the System.Win32 lib instead of doing the FFI directly.
Could you investigate what external functions we need exactly and if they're exported from System.Win32.
foreign import stdcall unsafe "windows.h GetModuleFileNameA" getModuleFileName :: Ptr () -> CString -> Int -> IO Int32 That's the only one. Wouldn't it make more sense to put this FFI call in Cabal (which is always there, and always required) instead of Win32, which isn't an existing dependancy? Thanks Neil
On Tue, Nov 07, 2006 at 06:55:38PM +0000, Neil Mitchell wrote:
However, I also want to develop Hoogle using WinHugs on Windows on a computer without a C compiler, and it seems that the generated Paths_Hoogle module requires FFI on Windows? Is there any way round this, or am I just out of luck in using Cabal's path feature in this situation?
Perhaps it could call things from the System.Win32 lib instead of doing the FFI directly.
Could you investigate what external functions we need exactly and if they're exported from System.Win32.
foreign import stdcall unsafe "windows.h GetModuleFileNameA" getModuleFileName :: Ptr () -> CString -> Int -> IO Int32
That's the only one. Wouldn't it make more sense to put this FFI call in Cabal (which is always there, and always required) instead of Win32, which isn't an existing dependancy?
Cabal isn't an existing dependency either (thought both will be present). Surely System.Win32.DLL.getModuleFileName is the Right Thing.
Hi
Cabal isn't an existing dependency either (thought both will be present). Surely System.Win32.DLL.getModuleFileName is the Right Thing.
My worry is that MinHugs has Cabal (as will pretty much every single Haskell compiler), but Win32 is a lot less commonly installed - for example GHC has moved it into Extralibs. I'd hate to introduce such a big dependency just for one single FFI function. Thanks Neil
On Tue, Nov 07, 2006 at 07:33:47PM +0000, Neil Mitchell wrote:
My worry is that MinHugs has Cabal (as will pretty much every single Haskell compiler), but Win32 is a lot less commonly installed - for example GHC has moved it into Extralibs.
Win32 is still a core package. Thanks Ian
Hi
My worry is that MinHugs has Cabal (as will pretty much every single Haskell compiler), but Win32 is a lot less commonly installed - for example GHC has moved it into Extralibs.
Win32 is still a core package.
Oh, my bad, I thought it had been moved out. Do you intend to leave Win32 as a core package for the future? Thanks Neil
On Wed, Nov 08, 2006 at 12:46:23AM +0000, Neil Mitchell wrote:
My worry is that MinHugs has Cabal (as will pretty much every single Haskell compiler), but Win32 is a lot less commonly installed - for example GHC has moved it into Extralibs.
Win32 is still a core package.
Oh, my bad, I thought it had been moved out. Do you intend to leave Win32 as a core package for the future?
There are no plans to move it out, as far as I know. If we could do so then that would be good, of course, as minimising the number of packages that ship with GHC is our goal. Incidentally, I'm not keen on needing a build-dep on Win32 on windows for every package that uses a magic paths module. I'm not familiar enough with it to suggest the right way, but I don't think it should be necessary for packagers to know about platform specific things like that (unless they are using platform specific packages (unix, Win32, ...) or using platform specific knowledge like the existence of things in /proc or functions imported with the FFI). Thanks Ian
On Tue, 2006-11-07 at 18:55 +0000, Neil Mitchell wrote:
Hi
However, I also want to develop Hoogle using WinHugs on Windows on a computer without a C compiler, and it seems that the generated Paths_Hoogle module requires FFI on Windows? Is there any way round this, or am I just out of luck in using Cabal's path feature in this situation?
Perhaps it could call things from the System.Win32 lib instead of doing the FFI directly.
Could you investigate what external functions we need exactly and if they're exported from System.Win32.
foreign import stdcall unsafe "windows.h GetModuleFileNameA" getModuleFileName :: Ptr () -> CString -> Int -> IO Int32
That's the only one. Wouldn't it make more sense to put this FFI call in Cabal (which is always there, and always required) instead of Win32, which isn't an existing dependancy?
Well I guess that's just the issue. Cabal also isn't an existing dependency. It'd be pretty bad to make every library & program depend on Cabal. Perhaps it's just as bad to make it depend on Win32, but I think it's probably less bad. Or it could go in base or we could leave it as is as an FFI import. Duncan
Hi
Well I guess that's just the issue. Cabal also isn't an existing dependency. It'd be pretty bad to make every library & program depend on Cabal. Perhaps it's just as bad to make it depend on Win32, but I think it's probably less bad. Or it could go in base or we could leave it as is as an FFI import.
The options: * Depend on win32 - plenty of users won't have this installed (since its no longer bundled by default) * Depend on FFI - most WinHugs users won't have C installed * Depend on Cabal - everyone with WinHugs or GHC will definitely have this installed. * Depend on base - everyone everywhere will have this installed, but requires changing base and there is no equivalent function on Posix (otherwise this would be a useful general purpose function) My vote goes in the direction of Cabal or base, since if its not one of those two I probably just won't bother using the Path functionality for Hoogle. Thanks Neil
On Tue, 2006-11-07 at 21:10 +0000, Neil Mitchell wrote:
Hi
Well I guess that's just the issue. Cabal also isn't an existing dependency. It'd be pretty bad to make every library & program depend on Cabal. Perhaps it's just as bad to make it depend on Win32, but I think it's probably less bad. Or it could go in base or we could leave it as is as an FFI import.
The options:
* Depend on win32 - plenty of users won't have this installed (since its no longer bundled by default)
It's not? Ok, I'm a bit surprised.
* Depend on FFI - most WinHugs users won't have C installed
So WinHugs isn't going to support the FFI spec? It's not clear that you need a C compiler to support the FFI. Python and GHC can compile without a C compiler and still do FFI.
* Depend on Cabal - everyone with WinHugs or GHC will definitely have this installed.
* Depend on base - everyone everywhere will have this installed, but requires changing base and there is no equivalent function on Posix (otherwise this would be a useful general purpose function)
My vote goes in the direction of Cabal or base, since if its not one of those two I probably just won't bother using the Path functionality for Hoogle.
But you see that it means that every package built with Cabal must then depend on Cabal? ie it'd have to go in build-depends for every single package! This would be very bad. What's more, it would mean that people would not do it on unix and it'd work, but then fail on windows because only on windows would the Paths_<pkg> module need Cabal. Actually that also applies to using the Win32 package or any non-base package. It's not something that people would really like to put into base because it's not portable. There really is no equivalent to GetModuleFileName in Unix (indeed deliberately so because you can delete the binary while the program is still running). I don't see a good solution apart from the current FFI solution. Duncan
Hi
* Depend on win32 - plenty of users won't have this installed (since its no longer bundled by default)
It's not? Ok, I'm a bit surprised.
MinHugs doesn't have it, the intention is to distribute GHC with less stuff, so I doubt it will be included for much longer by default.
* Depend on FFI - most WinHugs users won't have C installed
So WinHugs isn't going to support the FFI spec? It's not clear that you need a C compiler to support the FFI. Python and GHC can compile without a C compiler and still do FFI.
WinHugs indeed doesn't support the FFI spec unless you separately install a C compiler. You can use FFI libraries that have already been compiled, but not create new ones. GHC does this by bundling a full copy of GCC on Windows. Python does a similar thing to Yhc by doing wrapper less FFI - Hugs might be able to do that, but it currently doesn't, and would be a lot of work.
It's not something that people would really like to put into base because it's not portable. There really is no equivalent to GetModuleFileName in Unix (indeed deliberately so because you can delete the binary while the program is still running).
That doesn't stop people shoving in things that are Posix only :)
I don't see a good solution apart from the current FFI solution.
The only alternative solution I can come up with is to make a Hugs primitive on Windows, and then if you are compiling via Hugs on Windows the Paths thing can be done without FFI. Any other thoughts? Thanks Neil
On 11/7/06, Neil Mitchell
foreign import stdcall unsafe "windows.h GetModuleFileNameA" getModuleFileName :: Ptr () -> CString -> Int -> IO Int32
That's the only one. Wouldn't it make more sense to put this FFI call in Cabal (which is always there, and always required) instead of Win32, which isn't an existing dependancy?
Just a sidenote about this. If you import this code into Cabal, please consider using uncode version of this function GetModuleFileNameW (altghough that has slight problems with windows me and older if they don't have unicode extensions installed.) http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dllproc/bas... Best regards, Esa
On Tue, Nov 07, 2006 at 06:55:38PM +0000, Neil Mitchell wrote:
However, I also want to develop Hoogle using WinHugs on Windows on a computer without a C compiler, and it seems that the generated Paths_Hoogle module requires FFI on Windows? Is there any way round this, or am I just out of luck in using Cabal's path feature in this situation?
Perhaps it could call things from the System.Win32 lib instead of doing the FFI directly.
Could you investigate what external functions we need exactly and if they're exported from System.Win32.
foreign import stdcall unsafe "windows.h GetModuleFileNameA" getModuleFileName :: Ptr () -> CString -> Int -> IO Int32
That's the only one. Wouldn't it make more sense to put this FFI call in Cabal (which is always there, and always required) instead of Win32, which isn't an existing dependancy?
One moment. There's no point calling GetModuleFileName from runhugs, as the location of the runhugs binary has nothing to do with the package. The closest approximation is getProgName, the location of the source file containing the Main module. We'd just need some scheme for directories relative to that. Neil, how should be revise section 3.1.2 of the User's Guide for Hugs on Windows?
On Wed, Nov 08, 2006 at 01:27:44AM +0000, Ross Paterson wrote:
Neil, how should be revise section 3.1.2 of the [Cabal] User's Guide for Hugs on Windows?
The main thing is to decide where data files associated with a package should be stored. As I understand it, for Hugs on Windows the Haskell modules will be installed to $prefix\Haskell\hugs\programs\<progname> $prefix\Haskell\hugs\packages\$pkg for executables and libraries respectively. Should the data files also go in these directories, or somewhere else?
Hi
The main thing is to decide where data files associated with a package should be stored. As I understand it, for Hugs on Windows the Haskell modules will be installed to
$prefix\Haskell\hugs\programs\<progname> $prefix\Haskell\hugs\packages\$pkg
for executables and libraries respectively. Should the data files also go in these directories, or somewhere else?
Where do they go in GHC? Is that based on the location of the .exe or not? I think I remember Simon changing it recently so the answer is that its not. In which case, Hugs and GHC can have similar file locations. Thanks Neil
On Wed, Nov 08, 2006 at 02:48:33PM +0000, Neil Mitchell wrote:
Hi
The main thing is to decide where data files associated with a package should be stored. As I understand it, for Hugs on Windows the Haskell modules will be installed to
$prefix\Haskell\hugs\programs\<progname> $prefix\Haskell\hugs\packages\$pkg
for executables and libraries respectively. Should the data files also go in these directories, or somewhere else?
Where do they go in GHC? Is that based on the location of the .exe or not? I think I remember Simon changing it recently so the answer is that its not. In which case, Hugs and GHC can have similar file locations.
Ah, the answers (except for where Hugs puts program modules) are all in the table in section 3.1.2.1 of the Cabal User's Guide. We just need to adapt prefixFromBinDir for Hugs. (For Hugs, we might as well have prefix-independence under Unix too.) I might have a go at that some time, but someone else will need to test it under Windows.
Ah, the answers (except for where Hugs puts program modules) are all in the table in section 3.1.2.1 of the Cabal User's Guide. We just need to adapt prefixFromBinDir for Hugs. (For Hugs, we might as well have prefix-independence under Unix too.) I might have a go at that some time, but someone else will need to test it under Windows.
I am happy to test, feel free to either shove it in the repo, or mail me a darcs patch and I'll try it out. Thanks Neil
participants (5)
-
Duncan Coutts -
Esa Ilari Vuokko -
Ian Lynagh -
Neil Mitchell -
Ross Paterson