dvm (Was: denv - D version of rbenv)

[Nick Sabalausky]

"Jacob Carlborg" <doob at me.com> wrote in message 
news:jo1gri$1prf$1 at 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.)