Cabal Release Candidate

[Isaac Jones]

Brian Smith <brianlsmith at gmail.com> writes:

> I don't want to be a release manager (who does :). 

No idea... A guy can dream, can't he?  Maybe things will be better now
that I have a script.

> However, I noticed that Cabal doesn't seem to get tested much in
> Windows* so I can volunteer to be the semi-official tester for
> Windows.

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?

> 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.

> In particular, can we just skip support for GHC 6.4? The
> installation instructions for GHC 6.4 are workable, but it looks
> like the GHC 6.4.1 experience will be much better. Plus, I think
> that the package management changes between GHC 6.4.0 and 6.4.1 will
> cause problems for people packaging their stuff using Cabal. So,
> could we just say that Cabal 1.2 requires GHC 6.2.2 or GHC 6.4.1 or
> later?

I do indeed think that the next version of GHC will be better for
installing packages, but I don't think we should give up on 6.4.
OTOH, I don't think that it's a huge deal to just document the
difficulties.  It's really no harder than removing the old Cabal
before installing the new one.  Maybe we should just force everyone to
do that, or make that the default behavior for "make install".
That'll probably offend some folks' sensibilities.  What do folks here
think?

> * 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?

> * On GHC 6.4, trying to install Cabal 1.1.1 using Cabal 1.0 fails due
> to the bug in Cabal 1.0's "copy" command that I reported last month
> (which is fixed in Cabal 1.1.1). The workaround is to delete the
> "Executable: cabal-setup" stanza from Cabal.cabal. I believe that this
> executable is useless anyway.

It's not quite useless, but I really haven't decided if it's a good
idea.  I use it, so I expect others would like to as well.  But for
now, I'll remove it.  I didn't even document 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?

> * 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.

peace,

  isaac

p.s. these changes are in the darcs repo and on the latest snapshot
tarball on the web page, but not yet in the CVS repo.  I need to
figure out how to move a directory and keep darcs in sync w/ cvs
before I can commit there again.  Get the snapshot here:

http://www.haskell.org/cabal/code.html