RE: Remaining bugs in Cabal under Windows
On 16 August 2004 19:20, Krasimir Angelov wrote:
There still exists some bugs in Cabal when it is used under Windows.
- The platform dependent places in the code are marked with #ifdef mingw32_TARGET_OS but this macro is never defined ever under Windows. You must add -Dmingw32_TARGET_OS to the command line while building setup.exe and also add -Dmingw32_TARGET_OS to options-ghc field in Setup.description.
I'll fix this. Isaac: is it ok for me to commit fixes to the repository? I have a couple of other things I found when building Cabal on Windows recently, and Krasimir has sent me a large patch to fix a number of problems.
- When Cabal is used to build library package then it fails to find ar.exe in the path. This isn't a problem when in the build is run from cygwin or mingw environment but is painful on plain Command prompt.
Agreed - one of the goals of Cabal is that it should work with a plan GHC installation, no cygwin required. I think ar.exe should be packaged with GHC in the same directory as ghc.exe, so that it'll be available in the PATH. This is easier than providing ar functionality from GHC itself, which would perhaps be nice but is more work and is GHC-specific, you still have to invoke ar for other compilers.
- The package uses (getEnv "HOME") to get the path to home directory. The variable isn't present in plain Command prompt under Windows.
Agreed. I need to know the equivalent of $HOME for GHC too, so that GHC can keep a per-user package database.
- The default installation prefix under Windows is "C:\Program Files" but it is known that some times GHC doesn't work very well with paths which have spaces. I don't know whether this can be fixed or this depends from gcc and ld
GHC itself doesn't have problems with pathnames with spaces in; GHC's build system does, though. I claim: it should be a goal to make everything work for pathnames containing spaces.
To fix third bug I tried to use SHGetFolderPathAndSubDir function to retrieve the "Application Data" folder for current user. This is:
"C:\Documents and Settings\kr_angelov\Application Data"
on my PC. The trouble here is that to do that I need to add shell32 to extra-libs field in package description. I don't have a way to preprocess Setup.description so I can't add shell32 conditionally. I would like to have a collection of functions like:
getCurrentDirectory
we already have that
getAppUserDataDirectory getHomeDirectory
Maybe - although the conventions still differ between Unix and Windows. On Unix, to store per-user data you would use <homedir>/.<app> whereas on Windows you use <homedir>/<app>. So I think the win32 library should provide access to getAppUserDataDirectory, and the app code still needs to be conditionally compiled. Cheers, Simon
--- Simon Marlow
- When Cabal is used to build library package then it fails to find ar.exe in the path. This isn't a problem when in the build is run from cygwin or mingw environment but is painful on plain Command prompt.
Agreed - one of the goals of Cabal is that it should work with a plan GHC installation, no cygwin required. I think ar.exe should be packaged with GHC in the same directory as ghc.exe, so that it'll be available in the PATH. This is easier than providing ar functionality from GHC itself, which would perhaps be nice but is more work and is GHC-specific, you still have to invoke ar for other compilers.
You don't have to invoke ar for Hugs. NHC is working only with Cygwin so this is a trouble only with GHC. Is it so hard to invoke ar from GHC. This is alredy done for ld. Of course packaging ar in the GHC directory is a quick workaround.
To fix third bug I tried to use SHGetFolderPathAndSubDir function to retrieve the "Application Data" folder for current user. This is:
"C:\Documents and Settings\kr_angelov\Application Data"
on my PC. The trouble here is that to do that I
to add shell32 to extra-libs field in package description. I don't have a way to preprocess Setup.description so I can't add shell32 conditionally. I would like to have a collection of functions
need like:
getCurrentDirectory
we already have that
getAppUserDataDirectory getHomeDirectory
Maybe - although the conventions still differ between Unix and Windows. On Unix, to store per-user data you would use <homedir>/.<app> whereas on Windows you use <homedir>/<app>. So I think the win32 library should provide access to getAppUserDataDirectory, and the app code still needs to be conditionally compiled.
Instead we can provide function like: getAppUserDataDirectory :: String -> IO FilePath where getAppUserDataDirectory "<app>" will return <homedir>/.<app> or <homedir>\<app> Cheers, Krasimir __________________________________ Do you Yahoo!? Take Yahoo! Mail with you! Get it on your mobile phone. http://mobile.yahoo.com/maildemo
At 03:16 17/08/04 -0700, Krasimir Angelov wrote:
Maybe - although the conventions still differ between Unix and Windows. On Unix, to store per-user data you would use <homedir>/.<app> whereas on Windows you use <homedir>/<app>. So I think the win32 library should provide access to getAppUserDataDirectory, and the app code still needs to be conditionally compiled.
Instead we can provide function like:
getAppUserDataDirectory :: String -> IO FilePath
where getAppUserDataDirectory "<app>" will return <homedir>/.<app> or <homedir>\<app>
If we're going this way (which I think is a good thing), I think some more generic path query functions could be useful. When I ported the HaXml+HTTP libraries to windows, I needed to be able to find the current directory in order to convert a filename into a file: URI, in order to provide uniform handling of external entity access and base URI handling. The logic I used is somewhat ad-hoc, and can be seen here: http://www.ninebynine.org/Software/HaskellUtils/HaXml-1.12/src/Text/XML/HaXm... (See function "unsafeGetExtEntity".) There's some related logic I did for Hxml Toolbox to establish a default base URI: http://www.ninebynine.org/Software/HaskellUtils/HXmlToolbox-4.00/hparser/Xml... (see function "setDefaultURI".) All this raises questions about the correct correspondence between file: URIs and local filesystem names, which I've raised as a discussion point on the mailing list dealing with URI standardization: http://lists.w3.org/Archives/Public/uri/2004Jul/0009.html with some follow-up in a different thread: http://lists.w3.org/Archives/Public/uri/2004Jul/0013.html ... Anyway, I'd like to see the common library functions provide at least minimal capabilities to allow multi-platform applications to do the right thing when handling filenames. I'm pretty agnostic about what they actually look like, but as an example I've found the Python and/or Java libraries to be pretty usable in this respect. #g ------------ Graham Klyne For email: http://www.ninebynine.org/#Contact
"Simon Marlow"
On 16 August 2004 19:20, Krasimir Angelov wrote:
There still exists some bugs in Cabal when it is used under Windows.
- The platform dependent places in the code are marked with #ifdef mingw32_TARGET_OS but this macro is never defined ever under Windows. You must add -Dmingw32_TARGET_OS to the command line while building setup.exe and also add -Dmingw32_TARGET_OS to options-ghc field in Setup.description.
I'll fix this. Isaac: is it ok for me to commit fixes to the repository?
Sure, though I'm just as happy to accept the output from "darcs send" and integrate the patches in myself. I'm not sure that the test suite works everywhere, so I like to run the test suite myself. It would be nice if the test suite were actually portable, though. I have a patch of Krasimir's that I was just trying to push, but I can't reach cvs.haskell.org at the moment. (snip)
- The package uses (getEnv "HOME") to get the path to home directory. The variable isn't present in plain Command prompt under Windows.
Agreed. I need to know the equivalent of $HOME for GHC too, so that GHC can keep a per-user package database.
(snip)
on my PC. The trouble here is that to do that I need to add shell32 to extra-libs field in package description. I don't have a way to preprocess Setup.description so I can't add shell32 conditionally. I would like to have a collection of functions like:
getCurrentDirectory
we already have that
getAppUserDataDirectory getHomeDirectory
Maybe - although the conventions still differ between Unix and Windows. On Unix, to store per-user data you would use <homedir>/.<app> whereas on Windows you use <homedir>/<app>. So I think the win32 library should provide access to getAppUserDataDirectory, and the app code still needs to be conditionally compiled.
For what it's worth, I've been collecting various path-related functions and dumping them here, with the hope of organizing them later: darcs get http://www.syntaxpolice.org/darcs_repos/OS.Path/ Thank you both for your work on this, let me know how I can help :) peace, isaac
participants (4)
-
Graham Klyne -
Isaac Jones -
Krasimir Angelov -
Simon Marlow