From e0741782f943b86d3e55f699290cb1d5f577d803 Mon Sep 17 00:00:00 2001 From: simonpj Date: Tue, 11 Feb 2003 15:27:32 +0000 Subject: [PATCH] [project @ 2003-02-11 15:27:32 by simonpj] More Win32 notes --- ghc/docs/users_guide/win32-dlls.sgml | 131 +++++++++++++++++++++++++++++++--- 1 file changed, 122 insertions(+), 9 deletions(-) diff --git a/ghc/docs/users_guide/win32-dlls.sgml b/ghc/docs/users_guide/win32-dlls.sgml index 1435b18..96b5f1c 100644 --- a/ghc/docs/users_guide/win32-dlls.sgml +++ b/ghc/docs/users_guide/win32-dlls.sgml @@ -1,4 +1,116 @@ - + +Running GHC on Win32 systems + + + +Starting GHC on Win32 platforms + + +The installer that installs GHC on Win32 also sets up the file-suffix associations +for ".hs" and ".lhs" files so that double-clicking them starts ghci. + + +One little hitch happens if you right-click on a file, select "Open With..." and +then pick ghci. If the filename has spaces in, what will happen is +that GHC will get invoked like this: + + c:\ghc\bin\ghci \Documents and Settings\MyFile.lhs + +So it looks to GHC as if there are three arguments, "\Documents", "and", and "Settings\MyFile.lhs". + + Solution: don't use "Open With...", avoid spaces in file names, +or fiddle with the appropriate registry setting: + + HKEY_CLASSES_ROOT\Unknown\shell\openas\command + +Notice how the "%1" argument is quoted (or not). + + This problem doesn't occur when double-clicking. + + + + + + + +Using GHC (and other GHC-compiled executables) with cygwin + + +Background The cygwin tools aim to provide a +unix-style API on top of the windows libraries, to facilitate ports of +unix software to windows. To this end, they introduce a unix-style +directory hierarchy under some root directory (typically +/ is C:\cygwin\). Moreover, +everything built against the cygwin API (including the cygwin tools +and programs compiled with cygwin's ghc) will see / as the root of +their file system, happily pretending to work in a typical unix +environment, and finding things like /bin and /usr/include without +ever explicitly bothering with their actual location on the windows +system (probably C:\cygwin\bin and C:\cygwin\usr\include). + + + +The problem +GHC, by default, no longer depends on cygwin, but is a native +windows program. It is built using mingw, and it uses mingw's ghc +while compiling your Haskell sources (even if you call it from +cygwin's bash), but what matters here is that - just like any other +normal windows program - neither GHC nor the executables it produces +are aware of cygwin's pretended unix hierarchy. GHC will happily +accept either '/' or '\' as path separators, but it won't know where +to find /home/joe/Main.hs or /bin/bash +or the like. This causes all +kinds of fun when GHC is used from within cygwin's bash, or in +make-sessions running under cygwin. + + + +Things to do + + + Don't use absolute paths in make, configure & co if there is any chance + that those might be passed to GHC (or to GHC-compiled programs). Relative + paths are fine because cygwin tools are happy with them and GHC accepts + '/' as path-separator. And relative paths don't depend on where cygwin's + root directory is located, or on which partition or network drive your source + tree happens to reside, as long as you 'cd' there first. + + + + If you have to use absolute paths (beware of the innocent-looking + ROOT=`pwd` in makefile hierarchies or configure scripts), cygwin provides + a tool called cygpath that can convert cygwin's unix-style paths to their + actual windows-style counterparts. Many cygwin tools actually accept + absolute windows-style paths (remember, though, that you either need + to escape '\' or convert '\' to '/'), so you should be fine just using those + everywhere. If you need to use tools that do some kind of path-mangling + that depends on unix-style paths (one fun example is trying to interpret ':' + as a separator in path lists..), you can still try to convert paths using + cygpath just before they are passed to GHC and friends. + + + + If you don't have cygpath, you probably don't have cygwin and hence + no problems with it... unless you want to write one build process for several + platforms. Again, relative paths are your friend, but if you have to use + absolute paths, and don't want to use different tools on different platforms, + you can simply write a short Haskell program to print the current directory + (thanks to George Russell for this idea): compiled with GHC, this will give + you the view of the file system that GHC depends on (which will differ + depending on whether GHC is compiled with cygwin's gcc or mingw's + gcc or on a real unix system..) - that little program can also deal with + escaping '\' in paths. Apart from the banner and the startup time, + something like this would also do: + + $ echo "Directory.getCurrentDirectory >>= putStrLn . init . tail . show " | ghci + + + + + + + + Building and using Win32 DLLs @@ -18,7 +130,7 @@ cured the problem (it was supposedly fixed some years ago). - + Linking with DLLs @@ -55,9 +167,9 @@ statically. 4K for a "hello, world" application—not bad, huh? :-) - + - + Not linking with DLLs <IndexTerm><Primary>-static option (Win32)</Primary></IndexTerm> @@ -73,9 +185,9 @@ Notice that you cannot mix code that has been compiled with option on all the Haskell modules that make up your application. - + - + Creating a DLL @@ -183,10 +295,10 @@ non-static to static linking is simply a question of adding - + - + Making DLLs to be called from other languages @@ -306,8 +418,9 @@ the Haskell source and build the DLL. - + +