Hi, On Fri, Aug 31, 2012 at 5:34 AM, Mikhail Glushenkov <the.dead.shall.r...@gmail.com> wrote: > Hi, > > On Wed, Aug 29, 2012 at 1:45 AM, Johan Tibell <johan.tib...@gmail.com> wrote: > >> Perhaps a separate command, cabal init-sandbox, would be the best >> approach. Running that command would create the right package >> environment for running in a sandbox and the remaining commands would >> then use that sandbox. Separating init-sandbox from configure prevents >> the user from removing the sandbox preference when reconfiguring for >> some other reason (e.g. to add --enable-tests). To get out of the >> sandbox the user would edit the package environment file. > > One problem with a separate sandbox-init command is that it gives you > two ways to specify configure flags. E.g. you can do > > $ cabal sandbox-init -w /path/to/compiler-1 > $ cabal install --only-dependencies > > and then run > > $ cabal configure -w /path/to/compiler-2 > > which will rewrite the package environment file, but then fail due to > dependencies not being installed (since we are now using a different > compiler). It can also be a bit non-obvious that when you run > 'configure' after 'sandbox-init' it uses the configure flags given to > 'sandbox-init' earlier (saved in the package environment file).
Let's have sandbox-init not take any configure arguments. It should just mark that the current repo should use a sandbox until sandbox-delete is run. >>> I wouldn't change it yet. If at all, it should be a flag per >>> add-source. Not everything you add-source are libraries you >>> necessarily actively develop at the time. And I guess you can >>> add-source not only local packages, right? >> >> I'm worried about making cabal even more cumbersome to use. [...] >> If the use manually has to rebuild dependencies every time the change >> even when using a sandbox we have essentially no improvement over >> status quo and or cabal-dev. > > We can make automatic updating of dependencies the default and current > behaviour optional. In any case, we need to agree how to update > dependencies automatically. A naive algorithm is to just reinstall > everything (which is what cabal-dev does). We can try to be a bit > smarter and do something like the following: > > For each dependency added with add-source: > If the dependency has already been configured and there is no need to > reconfigure: > Either just run 'cabal build' and reinstall only if the produced > lib/exe is newer than the one we have installed, or get a list of all > source files for each target (is this possible?) and rebuild&reinstall > only if there is some source file newer than the installed target. > Otherwise just configure, build and install. > > Also, should this happen each time the user runs 'cabal build' or only > when running 'cabal install'? Here's an idea: as a compromise we can have cabal build imply reb-building and installing only add-source dependencies. This means nothing has to be downloaded from the internet. Lets not worry about minimize rebuilding now. Just call build in each add-source repo and reinstall the library. GHC will already skip most of the rebuilding (but not the relinking?). -- Johan _______________________________________________ cabal-devel mailing list cabal-devel@haskell.org http://www.haskell.org/mailman/listinfo/cabal-devel
