[Otakar Smrz] Cabal's `sdist` on Win32
Hi
-- line 133 replaced with these two system calls
system $ unwords ["tar -C", tmpDir, "-cf", tarBallFilePath, nameVersion pkg_descr] system $ unwords ["gzip -9", tarBallFilePath]
What was the original line here? And why are tar and gzip being used, when a much more "windows" thing to do would be to create a .zip file - although I guess thats not what people want. Thanks Neil
On Fri, 2006-10-20 at 23:15 +0100, Neil Mitchell wrote:
Hi
-- line 133 replaced with these two system calls
system $ unwords ["tar -C", tmpDir, "-cf", tarBallFilePath, nameVersion pkg_descr] system $ unwords ["gzip -9", tarBallFilePath]
So the version of tar there is too old to understand the -z flag?
What was the original line here? And why are tar and gzip being used, when a much more "windows" thing to do would be to create a .zip file - although I guess thats not what people want.
We'd still need a .zip file reader. I would suggest we ship zlib.dll on windows, and not use external tar or gzip programs, but then of course we run into the problem that there's nowhere to put the .dll that will work (unless someone can figure out how to use isolated .dlls and manifests and all that). So perhaps including a recent tar prog (that understands -z) would be the way forward. We'd need this for cabal-install in future, it's not just sdist. Duncan
Bringing Otakar back in on the discussion.
Duncan Coutts
On Fri, 2006-10-20 at 23:15 +0100, Neil Mitchell wrote:
Hi
-- line 133 replaced with these two system calls
system $ unwords ["tar -C", tmpDir, "-cf", tarBallFilePath, nameVersion pkg_descr] system $ unwords ["gzip -9", tarBallFilePath]
So the version of tar there is too old to understand the -z flag?
What was the original line here? And why are tar and gzip being used, when a much more "windows" thing to do would be to create a .zip file - although I guess thats not what people want.
We'd still need a .zip file reader.
I would suggest we ship zlib.dll on windows, and not use external tar or gzip programs, but then of course we run into the problem that there's nowhere to put the .dll that will work (unless someone can figure out how to use isolated .dlls and manifests and all that).
So perhaps including a recent tar prog (that understands -z) would be the way forward. We'd need this for cabal-install in future, it's not just sdist.
Do you mean just include it for windows? Including tar with cabal seems a bit over the top... Is there a pure Haskell tar or gzip or zip? We could just not compress things, I guess, if it's pretty common to have this older version of tar. peace, isaac
On Wed, 2006-10-25 at 09:48 -0700, Isaac Jones wrote:
I would suggest we ship zlib.dll on windows, and not use external tar or gzip programs, but then of course we run into the problem that there's nowhere to put the .dll that will work (unless someone can figure out how to use isolated .dlls and manifests and all that).
So perhaps including a recent tar prog (that understands -z) would be the way forward. We'd need this for cabal-install in future, it's not just sdist.
Do you mean just include it for windows?
Including tar with cabal seems a bit over the top... Is there a pure Haskell tar or gzip or zip?
Tar is easy to code, gzip is harder. Ian wrote some gunzip code in pure Haskell but I don't think there is a pure gzip Haskell compressor anywhere. I wrote some bindings to zlib, but then that needs the zlib C library of course. I don't think it's that over the top. If we intend to use .tar.gz as the cabal-install distribution format then windows users need to be able to decompress that. We could use some other format for which there is already a decompressor bundled with windows, eg .cab format. However generating that on non-windows machines is not easy. cabal-install is already one binary we'd be distributing, it's not that hard to bundle either zlib.dll or gzip.exe or tar.exe.
We could just not compress things, I guess, if it's pretty common to have this older version of tar.
As Neil said, Windows users don't have tar/gzip at all. Duncan
Neil Mitchell
What was the original line here? And why are tar and gzip being used, when a much more "windows" thing to do would be to create a .zip file - although I guess thats not what people want.
My point was that the current implementation of Hugs has it -- line 133 of Distribution.Simple.SrcDist system $ "(cd " ++ tmpDir ++ ";tar cf - " ++ (nameVersion pkg_descr) ++ ") | gzip -9 >" ++ tarBallFilePath which is not understood by cmd.exe in WinXP --- () and | are not supported. I therefore proposed the change of code so that it works: -- line 133 replaced with these two system calls system $ unwords ["tar -C", tmpDir, "-cf", tarBallFilePath, nameVersion pkg_descr] system $ unwords ["gzip -9", tarBallFilePath] -- also redefined to work with gzip tarBallName p = (nameVersion p) ++ ".tar" I had to install gzip and tar, of course, but they are available, so that is not a problem for me. However, if you and the other developers take this issue further as to removing the dependency on these external tools, the better for the users. Thank you, Otakar
participants (4)
-
Duncan Coutts -
Isaac Jones -
Neil Mitchell -
Otakar Smrz