I've updated the web page to have 1.0 (as Malcolm requested), and added 1.1.1, which is a "release candidate" for 1.2. Please forgive me for going insane with the version numbers. I'd appreciate it if early adopter types try out 1.1.1. In particular, check out the README wrt installing alongside-of or instead-of 1.0 with ghc 6.4. BTW, if anyone loves to manage releases and would like to relieve me of this duty so I can spend my time fixing bugs and adding features, just let me know ;) peace, isaac --------------------------------------------------------------- The Haskell Cabal The Common Architecture for Building Applications and Libraries. http://www.haskell.org/cabal IMPORTANT INFORMATION: See both the README file and the changelog for important interface changes and installation instructions. DOWNLOAD: The Haskell Cabal has reached version 1.1.1. This pre-release has a number of new features including a hook for testing, support for profiling, and support for _stub files, as well as several bug fixes. Download the Cabal here (source and debian versions available): http://www.haskell.org/cabal/download.html BUGS: Please report bugs and wish-list items to libraries@haskell.org and Isaac Jones: ijones@syntaxpolice.org. ABOUT: The Haskell Cabal is meant to be a part of a larger infrastructure for distributing, organizing, and cataloging Haskell Libraries and Tools. It is an effort to provide a framework for developers to more effectively contribute their software to the Haskell community. Specifically, the Cabal describes what a Haskell package is, how these packages interact with the language, and what Haskell implementations must to do to support packages. The Cabal also specifies some infrastructure (code) that makes it easy for tool authors to build and distribute conforming packages. The Cabal is only one contribution to the larger goal. In particular, the Cabal says nothing about more global issues such as how authors decide where in the module name space their library should live; how users can find a package they want; how orphan packages find new owners; and so on. NOTES: You cannot currently execute most setup scripts with "./Setup.lhs" since most systems do not have a runHaskell executable installed. You can compile it with ghc thusly: "ghc -package Cabal Setup.lhs -o setup" and then use the "setup" executable after that. This release is meant to provide the community with concrete information about how the interfaces are shaping up. This release does NOT fix the interfaces, we can't promise not to break anything that relies on these interfaces. We hope that Haskell authors will try to package their software using these tools, and let us know where they fall short. MORE INFORMATION: Please see the web site for the source code, interfaces, and especially the proposal, which will serve as documentation for this release: http://www.haskell.org/cabal/

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

On Sun, Jul 17, 2005 at 12:12:27PM -0500, Brian Smith wrote:

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

It's intended only for building the fptools libraries as part of the Hugs build, which is expected to take place inside Cygwin or MSYS/MinGW. As you say, it's no use to ordinary users -- something new is needed. On a system built with a compiler, cpphs and hsc2hs will be binaries and can be executed directly, but Hugs doesn't create binaries. Without a compiler, cpphs and hsc2hs will be shell scripts (or BAT files, though Cabal isn't set up for running those either). Any ideas? Another deficiency in Windows+Cabal is the lack of some counterpart of the scheme described in section 2.2 of the user's guide. It would probably suffice in many cases to have fixed variants of the system-specific files for each non-Unix system.

The documentation implies that, if I include the field: Hs-Source-Dirs: src in my Cabal package description, then _ONLY_ src will be considered the root source code directory. However, this is not the case. The current working directory is always implicitly part of Hs-Source-Dirs, at least when running with "runghc" or "runhugs." See the included testcase. It looks like this: .cabal file: .... Hs-Source-Dirs: src ... Main-Is: Main.hs files: Hs-Source-Dirs-Test-1.cabal Test1.hs src/Main.hs If the documentation was correct, then the package should fail to build because "Test1.hs" is in "." instead of in "src/". Yet, with both Hugs and GHC, the package builds successfully because they find Test1.hs in "." Yet, let's say I switch the locations of Test1.hs and Main.hs: Hs-Source-Dirs: src Main-Is: Main.hs files: Hs-Source-Dirs-Test-2.cabal Main.hs src/Test.hs I would guess, from the results of Test1, that Test2 should successfully build. Yet, it fails: with "Setup.hs: Main.hs doesn't exists" [sic].

From the results of these two tests, we can conclude that sometimes "." is part of the module search path, and sometimes it isn't. This is bad. Either "." should be always be implicitly part of the search path (better), or it should be implicitly part of the search path _only when no Hs-Source-Dirs field is present_ (best).

Secondly, I have seen references that say that all relative paths in a Cabal package are relative to the directory containing the package description. This is not true either. Instead, the whole Cabal library treats relative paths as relative to the current working directory. This is a problem for tools that want to reuse the Cabal API but potentially need to change the current working directly throughout their execution. For example, if we were to integrate some support for Cabal into GHCi, then this would interact badly with the :cd command. - Brian On 7/14/05, Isaac Jones wrote:

I've updated the web page to have 1.0 (as Malcolm requested), and added 1.1.1, which is a "release candidate" for 1.2. Please forgive me for going insane with the version numbers.

I'd appreciate it if early adopter types try out 1.1.1. In particular, check out the README wrt installing alongside-of or instead-of 1.0 with ghc 6.4.

BTW, if anyone loves to manage releases and would like to relieve me of this duty so I can spend my time fixing bugs and adding features, just let me know ;)

peace,

isaac

--------------------------------------------------------------- The Haskell Cabal The Common Architecture for Building Applications and Libraries. http://www.haskell.org/cabal

IMPORTANT INFORMATION:

See both the README file and the changelog for important interface changes and installation instructions.

DOWNLOAD:

The Haskell Cabal has reached version 1.1.1. This pre-release has a number of new features including a hook for testing, support for profiling, and support for _stub files, as well as several bug fixes.

Download the Cabal here (source and debian versions available): http://www.haskell.org/cabal/download.html

BUGS:

Please report bugs and wish-list items to libraries@haskell.org and Isaac Jones: ijones@syntaxpolice.org.

ABOUT:

The Haskell Cabal is meant to be a part of a larger infrastructure for distributing, organizing, and cataloging Haskell Libraries and Tools. It is an effort to provide a framework for developers to more effectively contribute their software to the Haskell community.

Specifically, the Cabal describes what a Haskell package is, how these packages interact with the language, and what Haskell implementations must to do to support packages. The Cabal also specifies some infrastructure (code) that makes it easy for tool authors to build and distribute conforming packages.

The Cabal is only one contribution to the larger goal. In particular, the Cabal says nothing about more global issues such as how authors decide where in the module name space their library should live; how users can find a package they want; how orphan packages find new owners; and so on.

NOTES:

You cannot currently execute most setup scripts with "./Setup.lhs" since most systems do not have a runHaskell executable installed. You can compile it with ghc thusly: "ghc -package Cabal Setup.lhs -o setup" and then use the "setup" executable after that.

This release is meant to provide the community with concrete information about how the interfaces are shaping up. This release does NOT fix the interfaces, we can't promise not to break anything that relies on these interfaces. We hope that Haskell authors will try to package their software using these tools, and let us know where they fall short.

MORE INFORMATION:

Please see the web site for the source code, interfaces, and especially the proposal, which will serve as documentation for this release:

http://www.haskell.org/cabal/ _______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries