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