Brian Smith
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