"Jacob Carlborg" <d...@me.com> wrote in message news:jo1gri$1prf$1...@digitalmars.com... > On 2012-05-04 21:38, Masahiro Nakagawa wrote: > >> Yes. But I don't know the detail of dvm implementation. >> rbenv is a small and compact version manager than rvm. >> (If you want to know more comparison of rbenv and rvm, >> See https://github.com/sstephenson/rbenv ) > > DVM can't even do half of the things RVM can. DVM can basically only > install compilers and switch between installed compilers. It can build DMD > as well, always forgets that. >
There's a little more work could probably be done on DVM's dmd-compiling. It doesn't support passing options to the makefiles. And IIRC it always does a full clean rebuild, it really should have "clean" separate, so you don't have to recompile *everything* every time. Speaking of, although I haven't had time to do anything on DVM lately (and probably won't anytime soon :( ), I have been thinking about what you said a while back about it needing some refactoring: Last time it was brought up, I was unsure of quite what you had in mind. I was under the impression that you wanted to redesign the whole way the command system *worked*. It's occurred to me that's maybe not what you meant? Were you thinking that the *system* of commands would work the same way as now, but just some commands/subcommands need to be moved around, the stuff that's kind of an ugly "internal psuedo-command" should be promoted to a true command/subcommand, etc? >> I like rbenv, so I ported. > > Fair enough. That's why I ported RVM :) > I had no idea it was ported from anything! :) (I've used Ruby, but mostly just for writing rakefiles.)