Cabal Release Candidate

[Brian Smith]

On 7/17/05, Isaac Jones <ijones at syntaxpolice.org> wrote:
> Brian Smith <brianlsmith at gmail.com> 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