dvm (Was: denv - D version of rbenv)

Jacob Carlborg doob at me.com
Fri May 4 15:03:40 PDT 2012


On 2012-05-04 23:31, Nick Sabalausky wrote:

> 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.

It doesn't a full rebuild of DMD at least. It seems to just invoke 
"make" which will notice that no files have changed and not compile 
anything.

> 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:

I neither haven't had time, or rather, I focused my time on other projects.

> 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 was mostly thinking of how the code is structured internally. 
Basically nothing would be changed from a user's point of view.

What I don't like is that all functionality is implemented in the 
command classes. The command classes should only handle the actual 
command and the flags for that given command. Then it should delegate to 
other classes for functions.

The "install" command is a perfect example of this. Currently the 
Install class inherits from Fetch, which is so wrong. It just does that 
to inherit the implementation, it's not an actual subtype. What should 
have been done is something like this (in some kind of pseudo code) :

class FetchCommand
{
     void execute ()
     {
         auto fetcher = new Fetcher;
         auto result = fetcher.fetch(args ...);
         store(result);
     }
}

class InstallCommand
{
     void execute ()
     {
         auto fetcher = new Fetcher;
         auto result = fetcher.fetch(args ...);

         auto installer = new Installer;
         installer.install(result);
     }
}

You can have a look at how Orbit it's structured as well. Structuring 
the code like this will also make it usable as a library (don't know if 
that would be useful in this case).

What should be changed from a user's point of view is that flags 
specific to a command should only be available to that command and not 
globally.

I was also hoping to factor out any compiler specific code in it's own 
classes/functions. This would make it possible handle other compilers 
like GDC, LDC and SDC. Although I don't think they provide pre-compiled 
binaries in the same way as DMD does.

-- 
/Jacob Carlborg


More information about the Digitalmars-d-announce mailing list