cabal-install uninstall ?
Hi! I'd like to get involved in haskell development and I think this could be a good start. I don't know how much time I'll have to do this, but if you give me that advice I'll try to implement this functionality.
So as you say, the way to do this would be to generate a list of files that will be installed. This can be used to later uninstall.
If you want to work on this feature I can provide some advice on how to implement it. It'll need a bit of work to restructure the install code so that it actually produces a list of things to install, rather than just installing them.
--
Henrique Ferreiro García
On Wed, 2008-05-14 at 11:28 +0200, Henrique Ferreiro García wrote:
Hi!
I'd like to get involved in haskell development and I think this could be a good start. I don't know how much time I'll have to do this, but if you give me that advice I'll try to implement this functionality.
Great. The place to look is the Distribution.Simple.Install module in the Cabal library. It currently directly calls functions like copyFileVerbose, copyDirectoryRecursiveVerbose and copyFiles. You'll want to look at each case and instead gather the files to be installed into one big list and then use a single call to copyFiles. Duncan
So as you say, the way to do this would be to generate a list of files that will be installed. This can be used to later uninstall.
If you want to work on this feature I can provide some advice on how to implement it. It'll need a bit of work to restructure the install code so that it actually produces a list of things to install, rather than just installing them.
_______________________________________________ cabal-devel mailing list cabal-devel@haskell.org http://www.haskell.org/mailman/listinfo/cabal-devel
It seems to be a little more complicated. Each compiler has a installExe and installLibs (or a joined install) functions which also mix collecting files and copying them. I think that the right thing to do would be to abstract away those compiler functions in a module with the same interface for all of them. Distribution.Simple.Compiler seems to be place. Moreover, something has to be done to decouple the file gathering from the copying phase in this functions, but I am not the correct person to decide how to do it. Any thoughts? O Mér, 14-05-2008 ás 10:48 +0100, Duncan Coutts escribiu:
On Wed, 2008-05-14 at 11:28 +0200, Henrique Ferreiro García wrote:
Hi!
I'd like to get involved in haskell development and I think this could be a good start. I don't know how much time I'll have to do this, but if you give me that advice I'll try to implement this functionality.
Great.
The place to look is the Distribution.Simple.Install module in the Cabal library. It currently directly calls functions like copyFileVerbose, copyDirectoryRecursiveVerbose and copyFiles.
You'll want to look at each case and instead gather the files to be installed into one big list and then use a single call to copyFiles.
Duncan
So as you say, the way to do this would be to generate a list of files that will be installed. This can be used to later uninstall.
If you want to work on this feature I can provide some advice on how to implement it. It'll need a bit of work to restructure the install code so that it actually produces a list of things to install, rather than just installing them.
_______________________________________________ cabal-devel mailing list cabal-devel@haskell.org http://www.haskell.org/mailman/listinfo/cabal-devel
--
Henrique Ferreiro García
On Fri, 2008-05-16 at 13:48 +0200, Henrique Ferreiro García wrote:
It seems to be a little more complicated. Each compiler has a installExe and installLibs (or a joined install) functions which also mix collecting files and copying them.
Ah yes.
I think that the right thing to do would be to abstract away those compiler functions in a module with the same interface for all of them. Distribution.Simple.Compiler seems to be place.
Right, we've wanted to do that for a while but there are other limitations stopping us from doing that yet.
Moreover, something has to be done to decouple the file gathering from the copying phase in this functions, but I am not the correct person to decide how to do it.
Indeed. We would want to change the installLibs/installExe for each compiler to return a set of files to copy. We can do that without changing to use a proper compiler abstraction. They're independent problems Duncan
The problem I see is that each compiler dependent function has its own post-install actions: GHC has stripExe, updateLibArchive..., Hugs has setPermissions, etc. Maybe, while this refactorization work isn't correctly done, a function could be done to return the list of files to update and the post-install function to execute, which could be a Maybe type associated with a particular file or a group of files. What do you think?
Indeed. We would want to change the installLibs/installExe for each compiler to return a set of files to copy. We can do that without changing to use a proper compiler abstraction. They're independent problems
Duncan
--
Henrique Ferreiro García
participants (2)
-
Duncan Coutts -
Henrique Ferreiro García