sdist runs tar, which is a problem under Windows

[bos]

(Imported from Trac #40, reported by @SyntaxPolice on 2006-01-09)

What do other tools do for tar in windows?

[bos]

(Imported comment by kr.angelov on 2006-01-09)

Currently sdist doesn't work under Windows. The problem is that the current implementation is using System.Cmd.system in platform dependent way. Instead rawSystem should be used. In this way sdist will work as long as you have tar & gzip in your search path. Since the .tar.gz format isn't very popular under Windows, I think that it would be usefull if we had support for more formats. At least support for .zip would be great. The other users may want another formats as well. The problem should be relativelly easy to fix. I will look at it when I find some more time.

[bos]

(Imported comment by @dcoutts on 2006-01-09)

Or write the tarfile from Haskell code. This shouldn't be very hard. It's a well documented format.

I wrote some code to do 'ar' format once, that was pretty easy. I don't expect 'tar' is much harder.

http://en.wikipedia.org/wiki/Tar_file_format

[bos]

(Imported comment by @dcoutts on 2006-08-02)

We have some code to do both g(un)zipping and reading and writing .tar format files however both add additional dependencies and on windows we have the issue that the zlib package needs zlib.dll. We could try bundling zlib.dll or try statically linking it. That would need some other build/distribution mechanism as cabal does not support that kind of thing yet. And there's always the annoying windows .dll path problem to consider.

[bos]

(Imported comment by @dcoutts on 2007-05-28)

Perhaps the sdist feature should be part of the cabal-install tool and not part of the Cabal library. Then it could use the zlib package as cabal-install does. That would be a solution for Windows. The Cabal library could provide functions just to prepare the sdist temporary directory but not the bit that actually packs that up into a .tar.gz file.

[bos]

(Imported comment by ross on 2007-10-26)

It makes sense to take sdist out of the library, as it's not essential for building, and would work better with these extra dependencies. But I'm not sure about bundling everything in an all-purpose program. Small special-purpose tools have fewer dependencies and avoid many coordination issues. More of them (cabal-deb, cabal-rpm, cabal-msi, etc) can be added by third parties without looking second class.

[bos]

(Imported comment by @dcoutts on 2007-11-16)

Replying to ross:

It makes sense to take sdist out of the library, as it's not essential for building, and would work better with these extra dependencies.

Yes.

But I'm not sure about bundling everything in an all-purpose program. Small special-purpose tools have fewer dependencies and avoid many coordination issues. More of them (cabal-deb, cabal-rpm, cabal-msi, etc) can be added by third parties without looking second class.

I don't think it is necessary to bundle everything into one program. I think it is good to have everything unified under one command from a user interface point of view. For example we should be able to set things up so cabal-rpm, cabal-deb etc provide the rpm and deb commands for the cabal tool.

$ cabal --help

should list all commands

$ cabal rpm

should call out to cabal-rpm or whatever helper is registered.

[bos]

(Imported comment by @dcoutts on 2007-11-16)

Fixed:

Tue Mar 18 17:30:47 GMT 2008  Andrea Vezzosi <sanzhiyan@gmail.com>
  * FIX #40, now cabal sdist creates the archive using Hackage.Tar
  we don't call setup sdist anymore but we use functions from
  Distribution.Simple.SrcDist