Re: Cabal Release Candidate

On 7/17/05, Isaac Jones wrote:

Brian Smith writes:

That's super! I'm CCing Krasimir because he's our Windows go-to guy. Maybe we can get the test suite in better shape for Windows. What happens when you "make check"? Does it all just explode?

Although I normially use MSYS/MinGW, I did all my testing without it because GHC does not require MSYS or MinGW. In other words, I didn't use "make" because Windows doesn't have "make." Instead, I installed Cabal like I would install any other Cabal package (see below).

...

However, I would like to know what versions of GHC, NHC, and Hugs you want to support for the Cabal 1.2 release on Windows. (I don't normally use NHC at all but I'm not opposed to doing some basic tests with it).

I would like to support all of the recently released tools. NHC doesn't yet have proper Cabal support; it just comes with Cabal, and the Hugs version is March 2005.

Hugs/March 2005 for Windows has not been released yet. I am not sure if it is even in a buildable condition. This means that there is no Cabal-capable Hugs on Windows.

...

* The new call to SHGetFolderPath does not get linked correctly, causing Cabal 1.1.1 to not work once it is installed due to linker failure. At least part of the problem is that The foreign import declaration in Disbribution.Simple.Configure should be: - foreign import stdcall unsafe "SHGetFolderPath" + foreign import stdcall unsafe "SHGetFolderPathA" or - foreign import stdcall unsafe "SHGetFolderPath" +foreign import stdcall unsafe "SHGetFolderPathW"

depending on whether or not you are expecting ANSI or Unicode results. You probably want the Unicode version because the "Program Files" folder can contain Arabic, Japanese, etc. characters that ANSI can't represent.

I made this change; of course, I can't test it. Can anyone enlighten me as to why this is incorrect? Is this the correct name on some version of some compilers or windows? Do we need more ifdefs to get this exactly right?

In the Windows API, for every function xxx that deals with user-visible strings, there are two versions provided: an ANSI (single-byte characters) version named xxxA and a unicode version (wide characters) named xxxW. There is never a function named just xxx. Rather, the C/C++ header files have something like #ifdef USE_WIDE_CHARS #define xxx xxxW #else #define xxx xxxA #endif I am not an authority on this, but I believe the jist is right. Unfortunately, I don't know enough about low-level Windows programming or the Haskell FFI to give you a patch. I suggest looking in the Win32 package to see how that code deals with it.

...

* In Distribution.Preprocess, there are two places where you have this: #if __HUGS__ && mingw32_TARGET_OS = rawSystemVerbose verbose "sh" (cpphs : extraArgs ++ ["-O" ++ outFile, inFile]) #else

If I am reading this correctly then it doesn't make sense because you can't assume that all Hugs users on Windows users have a "sh" executable.

Can anyone else comment on this? Why is this like that? Why not just call it the way we call it in Unix?

I assume that this code is attempting to execute a program named "sh" On windows, there is no program named "sh" or "sh.exe" because Windows doesn't have the Bourne shell, just like Windows usually doesn't have GNU Make. Even though the target name is "mingw32_TARGET_OS," you can't assume that the user actually has MinGW/MSYS installed; a more accurate name for the target would be "w32_TARGET_OS". I am not sure why cpphs is not just executed directly (instead of being executed through SH) in this code. But, anyway, it doesn't matter in the short-term as Hugs+Windows+Cabal doesn't exist currently.

...

* It should be possible for Windows users to build Cabal 1.1.1 on both GHC 6.2.2 and GHC 6.4.1 without having GNU make installed. This process needs to be documented. I will wait to send you the docs until I find out if GHC 6.4(.0) will be supported in Cabal 1.2.

Yes, I would like to support it. The only extra steps are those in the "make setup" command, which is just a couple of extra flags to GHC for bootstrapping. A batch file / shell script would actually work just as well. The GNUMakefile is really just a glorified shell script.

If you put {-# OPTIONS -cpp #-} on all the Cabal source files that need preprocessing, then you can install Cabal 1.1.1 exactly like any other cabal package on GHC >= 6.4. runghc Setup.lhs configure runghc Setup.lhs build runghc Setup.lhs install The only reason that it doesn't work on GHC 6.2.2 is because there is no "runghc" in that version. For GHC 6.2.2 and later, this seems to work: ghc -cpp --make Setup.lhs -o setup setup configure setup build setup install However, it won't work for Hugs unless runhugs has something equivalent to {#- OPTIONS -cpp #-} - Brian