Jason Dagit <[email protected]> writes: > The ghci target was notoriously flaky, but when it did work it was very > valuable (to me anyway). Usually when it was failing, if I did a full build > first and then used the target everything would work. Sometimes it was the > opposite that worked (doing a clean followed by make ghci). > > I don't have a machine handy to try what you're saying, but I never really had > much luck with it in the past. Does cabal-install make this easier some how? > > In other words, I'm sad to see this feature go away. Well, with Cabal 1.8, we'll be able to create in-place library registrations: with this, it should be quite easy to put back a sort of make ghci that would:
cabal build ghci -package-conf dist/path/to/inplace-package-conf (+ maybe some -package magic) Otherwise, make ghci is tricky, since it needs to compile the .c files which requires a lot of logic we don't want. > - make install: cabal currently does not install the manual (since it > cannot > build it) > > > This sounds bad. We have 6 months to fix it. > I'm glad you're asking people about these. It's quite possible someone is > using them. The windows installer one sounds important/valuable to me at > least > (then again, I didn't check the makefile to see what it actually does). I'm quite sure windows installer is broken for a few years now. > I'd like to just say once more, that I don't think we need to get rid of the > autoconf/make based build. I believe adding cabal support was a great idea, > but I'm still not convinced that cabal and autoconf/make need to be mutually > exclusive here. Supporting autoconf has already cost me many hours of release management time. I will be very glad when it is finally gone. They don't need to be mutually exclusive, it's just that keeping autoconf alive is more work than it is worth. And having around a broken build system is dangerous at best (even right now it cannot compile darcs correctly: you need to read the .cabal file and install the right packages manually -- or you will get either compile failures (better case) or you will get a silently broken, buggy darcs... this will get even more dangerous in the future, as we rely more on the hackage libraries). Yours, Petr. _______________________________________________ darcs-users mailing list [email protected] http://lists.osuosl.org/mailman/listinfo/darcs-users
