www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - DVM - D Version Manager 0.4.0

reply Jacob Carlborg <doob me.com> writes:
I just released a new version of DVM, 0.4.0. The only thing new in this 
release in the "compile" command. This allows to compile DMD, druntime 
and Phobos from github. Create a folder, clone DMD, druntime and Phobos 
in the newly create folder, run "dvm compile folder" to compile 
everything. The compiler is placed in the DMD directory.

For installation instructions see: https://bitbucket.org/doob/dvm

Changelog:

Version 0.4.0
   New/Change Features
     * Added a "compile" command for compiling DMD, druntime and Phobos 
from github

-- 
/Jacob Carlborg
Jan 06 2012
next sibling parent reply Robert Clipsham <robert octarineparrot.com> writes:
On 06/01/2012 21:29, Jacob Carlborg wrote:

 I just released a new version of DVM, 0.4.0. The only thing new in this
 release in the "compile" command. This allows to compile DMD, druntime
 and Phobos from github. Create a folder, clone DMD, druntime and Phobos
 in the newly create folder, run "dvm compile folder" to compile
 everything. The compiler is placed in the DMD directory.

 For installation instructions see: https://bitbucket.org/doob/dvm

 Changelog:

 Version 0.4.0
 New/Change Features
 * Added a "compile" command for compiling DMD, druntime and Phobos from
 github


This is excellent, can't wait to try it out!

Would it be possible to get something like this working?






-- 
Robert
http://octarineparrot.com/
Jan 06 2012
parent reply "Nick Sabalausky" <a a.a> writes:
"Robert Clipsham" <robert octarineparrot.com> wrote in message 
news:je7qkg$1s8f$1 digitalmars.com...

 Would it be possible to get something like this working?







Yea, both Jacob and I wanted to get that sort of thing in, and it shouldn't 
be too hard. But neither of us have quite gotten around to it yet.
Jan 06 2012
parent reply Jacob Carlborg <doob me.com> writes:
On 2012-01-07 00:58, Nick Sabalausky wrote:

 "Robert Clipsham"<robert octarineparrot.com>  wrote in message
 news:je7qkg$1s8f$1 digitalmars.com...

 Would it be possible to get something like this working?







 Yea, both Jacob and I wanted to get that sort of thing in, and it shouldn't
 be too hard. But neither of us have quite gotten around to it yet.


I would really like to do a complete rewrite of the tool, the internals. 
Well actually more of a complete refactoring so DVM can be built as a 
library and the tool uses the library. This would make things like the 
above much easier to integrate.

-- 
/Jacob Carlborg
Jan 07 2012
parent reply "Nick Sabalausky" <a a.a> writes:
"Jacob Carlborg" <doob me.com> wrote in message 
news:je9fbv$1heb$2 digitalmars.com...

 On 2012-01-07 00:58, Nick Sabalausky wrote:

 "Robert Clipsham"<robert octarineparrot.com>  wrote in message
 news:je7qkg$1s8f$1 digitalmars.com...

 Would it be possible to get something like this working?







 Yea, both Jacob and I wanted to get that sort of thing in, and it 
 shouldn't
 be too hard. But neither of us have quite gotten around to it yet.


 I would really like to do a complete rewrite of the tool, the internals. 
 Well actually more of a complete refactoring so DVM can be built as a 
 library and the tool uses the library. This would make things like the 
 above much easier to integrate.


Interesting. Do you have any sort of idea on when, or a rough roadmap? Or is 
it one of those "One of things days if I get around to it" sort of thing 
(that I'm all too familiar with myself!)?
Jan 07 2012
parent reply "Nick Sabalausky" <a a.a> writes:
"Nick Sabalausky" <a a.a> wrote in message 
news:jeaaae$304r$1 digitalmars.com...

 "Jacob Carlborg" <doob me.com> wrote in message 
 news:je9fbv$1heb$2 digitalmars.com...

 I would really like to do a complete rewrite of the tool, the internals. 
 Well actually more of a complete refactoring so DVM can be built as a 
 library and the tool uses the library. This would make things like the 
 above much easier to integrate.


 Interesting. Do you have any sort of idea on when, or a rough roadmap? Or 
 is it one of those "One of things days if I get around to it" sort of 
 thing (that I'm all too familiar with myself!)?


I guess what I'm really getting at is: Is the refactoring you have in mind 
something that should ideally come before other new features? Or would that 
not really matter?
Jan 07 2012
parent reply Jacob Carlborg <doob me.com> writes:
On 2012-01-07 21:39, Nick Sabalausky wrote:

 "Nick Sabalausky"<a a.a>  wrote in message
 news:jeaaae$304r$1 digitalmars.com...

 "Jacob Carlborg"<doob me.com>  wrote in message
 news:je9fbv$1heb$2 digitalmars.com...

 I would really like to do a complete rewrite of the tool, the internals.
 Well actually more of a complete refactoring so DVM can be built as a
 library and the tool uses the library. This would make things like the
 above much easier to integrate.


 Interesting. Do you have any sort of idea on when, or a rough roadmap? Or
 is it one of those "One of things days if I get around to it" sort of
 thing (that I'm all too familiar with myself!)?


 I guess what I'm really getting at is: Is the refactoring you have in mind
 something that should ideally come before other new features? Or would that
 not really matter?


Ideally it should come before other new features. I mean, the more stuff 
we put in there the more mess it will be. The point of the refactoring 
is of course to make it easier to add new features and to understand the 
code.

I'm not really sure about the road map. I'm currently focusing on Orbit, 
the package manager I'm developing. Also the main goal of DVM is already 
done. Hopefully I can squeeze in some time to work on DVM before the 
first release of Orbit.

About the refactoring, what to you think about these:

* Move to git
* Move to github
* Port to D2, still using Tango

-- 
/Jacob Carlborg
Jan 08 2012
parent reply "Nick Sabalausky" <a a.a> writes:
"Jacob Carlborg" <doob me.com> wrote in message 
news:jec1j6$2rbu$1 digitalmars.com...

 Ideally it should come before other new features. I mean, the more stuff 
 we put in there the more mess it will be. The point of the refactoring is 
 of course to make it easier to add new features and to understand the 
 code.


Yea, that makes sense. I guess I just wasn't sure how "deep" the refactoring 
you were envisioning was going to be.

Something possibly releated I've been meaning to bring up: I've been 
thinking that DVM's commands and options should work more like, say, git or 
svn. By that I mean: Right now DVM has a set of commands, and a set of 
"global" DVM options. Problem is, some of the options only apply to some of 
the commands. This sugegsts a few changes:

1. "dvm --help" should only show globally-applicable options. (--verbose 
and --help are probably only ones right now.)

2. "dvm [command] --help" (and maybe "dvm --help [command]", too) should 
show a command-specific help screen.

This isn't a *huge* need right now, but I think it'll only become more and 
more important as DVM progresses. I don't know if this is something that 
should be taken into account in the refactoring, or just left until after.

Another thing that might need to be considered in the refactoring: On Linux, 
DVM doesn't currently work inside a shell script. It's just not recognized. 
I'm sure it probably has something to do with the "dvm" shell-function. 
Maybe it's because it's set to only be defined on interactive prompts? I 
don't really know for certain what the problem or the solution is, so 
depending on whatever the "right" solution is, this might be a "take into 
account in the refactoring" matter.



 About the refactoring, what to you think about these:

 * Move to git


I don't have a really strong opinion on that. While I kind of like Hg a 
little better, I normally use the Tortoise tools, and I like TortoiseGit 
much better than TortoiseHg. Also branching is built into Git rather than 
being a grafted-on extra, which is nice. (And of course, DVM goes 
hand-in-hand with DMD and DMD is Git). So I guess I would lean more towards 
Git, but either way works.



 * Move to github


It's ultimately up to you, but personally I can't stand Github. My vote 
would be to stick with Bitbucket.

Granted, I haven't actually tried Bitbucket's Git support yet. But just 
yesterday I started the process of converting a couple of my projects from 
SVN/Dsource to Git/Bitbucket, so we'll see how it goes, and I'll let you 
know.



 * Port to D2, still using Tango


I'm definitely in favor of switching to D2. In fact, I took the leap from 
D1/Tango straight to D2/Phobos on my own projects about a year or so ago, so 
I have some experience in that (and D2's only gotten better since), and I'd 
be happy to take the lead converting it to D2. I found that the vast 
majority of changes I needed to make were Tango->Phobos because, while there 
are some breaking changes from D1->D2, most of the changes are additive, and 
D1-style code works fine in D2 with only very little change.

As far as Tango: I have no idea what the state of D2's Tango is, and 
personally I'd prefer Phobos. But if you have reason to believe D2's Tango 
is ready to use and you'd prefer that, then I'm perfectly fine with it. 
Actually, heck, if we're going to switch to D2, we may as well at least give 
D2's Tango a try along the way. If it works, it works, if it doesn't we can 
help out D2's Tango or just do Phobos (especially since 2.058 will have that 
new curl module).
Jan 08 2012
next sibling parent "Nick Sabalausky" <a a.a> writes:
"Nick Sabalausky" <a a.a> wrote in message 
news:jecuno$18e6$1 digitalmars.com...

 Something possibly releated I've been meaning to bring up: I've been 
 thinking that DVM's commands and options should work more like, say, git 
 or svn. By that I mean: Right now DVM has a set of commands, and a set of 
 "global" DVM options. Problem is, some of the options only apply to some 
 of the commands. This sugegsts a few changes:

 1. "dvm --help" should only show globally-applicable options. (--verbose 
 and --help are probably only ones right now.)

 2. "dvm [command] --help" (and maybe "dvm --help [command]", too) should 
 show a command-specific help screen.


3. Use of inapplicable options, like "dvm --default fetch 2.057", should be 
an error.


 This isn't a *huge* need right now, but I think it'll only become more and 
 more important as DVM progresses. I don't know if this is something that 
 should be taken into account in the refactoring, or just left until after.
Jan 08 2012
prev sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2012-01-08 21:34, Nick Sabalausky wrote:

 "Jacob Carlborg"<doob me.com>  wrote in message
 news:jec1j6$2rbu$1 digitalmars.com...

 Ideally it should come before other new features. I mean, the more stuff
 we put in there the more mess it will be. The point of the refactoring is
 of course to make it easier to add new features and to understand the
 code.


 Yea, that makes sense. I guess I just wasn't sure how "deep" the refactoring
 you were envisioning was going to be.


Quite deep. I want to have it look more like Orbit: 
https://github.com/jacob-carlborg/orbit

Instead of having all code in the commands I want to have a single class 
for a single task. The commands would then basically just create a new 
instance of the needed classes.


 Something possibly releated I've been meaning to bring up: I've been
 thinking that DVM's commands and options should work more like, say, git or
 svn. By that I mean: Right now DVM has a set of commands, and a set of
 "global" DVM options. Problem is, some of the options only apply to some of
 the commands. This sugegsts a few changes:

 1. "dvm --help" should only show globally-applicable options. (--verbose
 and --help are probably only ones right now.)

 2. "dvm [command] --help" (and maybe "dvm --help [command]", too) should
 show a command-specific help screen.

 This isn't a *huge* need right now, but I think it'll only become more and
 more important as DVM progresses. I don't know if this is something that
 should be taken into account in the refactoring, or just left until after.


Yeah, I know. That would be another reason to do the refactoring.


 Another thing that might need to be considered in the refactoring: On Linux,
 DVM doesn't currently work inside a shell script. It's just not recognized.
 I'm sure it probably has something to do with the "dvm" shell-function.
 Maybe it's because it's set to only be defined on interactive prompts? I
 don't really know for certain what the problem or the solution is, so
 depending on whatever the "right" solution is, this might be a "take into
 account in the refactoring" matter.


I didn't know about that. I'll take a look at that.


 About the refactoring, what to you think about these:

 * Move to git


 I don't have a really strong opinion on that. While I kind of like Hg a
 little better, I normally use the Tortoise tools, and I like TortoiseGit
 much better than TortoiseHg. Also branching is built into Git rather than
 being a grafted-on extra, which is nice. (And of course, DVM goes
 hand-in-hand with DMD and DMD is Git). So I guess I would lean more towards
 Git, but either way works.


I've moved all my projects to git, use it at work, so I prefer it over 
mercurial.


 * Move to github


 It's ultimately up to you, but personally I can't stand Github. My vote
 would be to stick with Bitbucket.

 Granted, I haven't actually tried Bitbucket's Git support yet. But just
 yesterday I started the process of converting a couple of my projects from
 SVN/Dsource to Git/Bitbucket, so we'll see how it goes, and I'll let you
 know.


I'm asking you since you're the main contributor next to me. I prefer 
Github, many D project are moving to Github, DMD, Phobos and druntime 
are already there. But certainly don't want to push you away, that 
wouldn't be good for the Windows port :)


 * Port to D2, still using Tango


 I'm definitely in favor of switching to D2. In fact, I took the leap from
 D1/Tango straight to D2/Phobos on my own projects about a year or so ago, so
 I have some experience in that (and D2's only gotten better since), and I'd
 be happy to take the lead converting it to D2. I found that the vast
 majority of changes I needed to make were Tango->Phobos because, while there
 are some breaking changes from D1->D2, most of the changes are additive, and
 D1-style code works fine in D2 with only very little change.

 As far as Tango: I have no idea what the state of D2's Tango is, and
 personally I'd prefer Phobos. But if you have reason to believe D2's Tango
 is ready to use and you'd prefer that, then I'm perfectly fine with it.
 Actually, heck, if we're going to switch to D2, we may as well at least give
 D2's Tango a try along the way. If it works, it works, if it doesn't we can
 help out D2's Tango or just do Phobos (especially since 2.058 will have that
 new curl module).


I'm pretty sure Tango for D2 is ready enough. I got help porting my 
package manager, Orbit, to D2 using Tango. Everything compiles but not 
everything works, probably something D2 and Ruby related (TLS or 
something like that). But it was surprisingly few changes that needed to 
be done and that is all to Tango working with D2. The biggest problem 
would be to port the tool to use Phobos instead of Tango.

I guess it would be best to start by adding some high level tests to 
DVM. You probably won't like this but there's a great Ruby tool for 
testing these kind of things called Cucumber. I'm already using it in 
Orbit: https://github.com/jacob-carlborg/orbit/tree/master/features

-- 
/Jacob Carlborg
Jan 08 2012
parent reply "Nick Sabalausky" <a a.a> writes:
"Jacob Carlborg" <doob me.com> wrote in message 
news:jee58o$54v$1 digitalmars.com...

 On 2012-01-08 21:34, Nick Sabalausky wrote:

 "Jacob Carlborg"<doob me.com>  wrote in message
 news:jec1j6$2rbu$1 digitalmars.com...

 * Move to github


 It's ultimately up to you, but personally I can't stand Github. My vote
 would be to stick with Bitbucket.

 Granted, I haven't actually tried Bitbucket's Git support yet. But just
 yesterday I started the process of converting a couple of my projects 
 from
 SVN/Dsource to Git/Bitbucket, so we'll see how it goes, and I'll let you
 know.


 I'm asking you since you're the main contributor next to me. I prefer 
 Github, many D project are moving to Github, DMD, Phobos and druntime are 
 already there. But certainly don't want to push you away, that wouldn't be 
 good for the Windows port :)


While I would find github more painful, it wouldn't make me decrease my 
contributions to DVM. DVM's too important a tool, IMO (Much like RDMD, which 
I also contribute too).

Heck, maybe if we're lucky that OSX desktop interface to github will someday 
get ported to Lin or Win :)

I'm on my way to bed so I'll check out those links later. (FWIW, I don't 
think Ruby's all that bad as far as dynamic langauges go. Probably one of 
the best, actually. It's just no D ;) )
Jan 09 2012
next sibling parent Jacob Carlborg <doob me.com> writes:
On 2012-01-09 10:14, Nick Sabalausky wrote:

 "Jacob Carlborg"<doob me.com>  wrote in message
 news:jee58o$54v$1 digitalmars.com...

 On 2012-01-08 21:34, Nick Sabalausky wrote:

 "Jacob Carlborg"<doob me.com>   wrote in message
 news:jec1j6$2rbu$1 digitalmars.com...

 * Move to github


 It's ultimately up to you, but personally I can't stand Github. My vote
 would be to stick with Bitbucket.

 Granted, I haven't actually tried Bitbucket's Git support yet. But just
 yesterday I started the process of converting a couple of my projects
 from
 SVN/Dsource to Git/Bitbucket, so we'll see how it goes, and I'll let you
 know.


 I'm asking you since you're the main contributor next to me. I prefer
 Github, many D project are moving to Github, DMD, Phobos and druntime are
 already there. But certainly don't want to push you away, that wouldn't be
 good for the Windows port :)


 While I would find github more painful, it wouldn't make me decrease my
 contributions to DVM. DVM's too important a tool, IMO (Much like RDMD, which
 I also contribute too).


I'm glad to hear to. I'll have to think about it then.


 Heck, maybe if we're lucky that OSX desktop interface to github will someday
 get ported to Lin or Win :)

 I'm on my way to bed so I'll check out those links later. (FWIW, I don't
 think Ruby's all that bad as far as dynamic langauges go. Probably one of
 the best, actually. It's just no D ;) )


Hehe, ok.

-- 
/Jacob Carlborg
Jan 09 2012
prev sibling parent reply Russel Winder <russel russel.org.uk> writes:
Nick,

'scuse me butting in...

On Mon, 2012-01-09 at 04:14 -0500, Nick Sabalausky wrote:
[...]

 Heck, maybe if we're lucky that OSX desktop interface to github will some=


day=20

 get ported to Lin or Win :)


[...]

Is there any need for a GUI to GitHub?  Isn't having a GUI for the local
clone all you need along with the browser UI to GitHub?  Using remote
tracking branches allows almost all activity other than pull requests to
be done locally with gitg or somesuch.

--=20
Russel.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder ekiga.n=
et
41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel russel.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder
Jan 13 2012
parent Jacob Carlborg <doob me.com> writes:
On 2012-01-13 10:58, Russel Winder wrote:

 Nick,

 'scuse me butting in...

 On Mon, 2012-01-09 at 04:14 -0500, Nick Sabalausky wrote:
 [...]

 Heck, maybe if we're lucky that OSX desktop interface to github will someday
 get ported to Lin or Win :)


 [...]

 Is there any need for a GUI to GitHub?  Isn't having a GUI for the local
 clone all you need along with the browser UI to GitHub?  Using remote
 tracking branches allows almost all activity other than pull requests to
 be done locally with gitg or somesuch.


I have never had a use for a GUI for git.

-- 
/Jacob Carlborg
Jan 13 2012
prev sibling next sibling parent reply "Nick Sabalausky" <a a.a> writes:
"Jacob Carlborg" <doob me.com> wrote in message 
news:je7p3p$1pl1$1 digitalmars.com...

I just released a new version of DVM, 0.4.0. The only thing new in this 
release in the "compile" command. This allows to compile DMD, druntime and 
Phobos from github. Create a folder, clone DMD, druntime and Phobos in the 
newly create folder, run "dvm compile folder" to compile everything. The 
compiler is placed in the DMD directory.


In other words:

$ git clone https://github.com/D-Programming-Language/dmd.git
$ git clone https://github.com/D-Programming-Language/druntime.git
$ git clone https://github.com/D-Programming-Language/phobos.git
$ git clone https://github.com/D-Programming-Language/tools.git
but this is optional
$ dvm compile

DMD32 D Compiler v2.0...
...etc...

If you notice it downloading the latest DMD release before compiling, 
there's a reason for that: There are some files (from the bin and lib 
directories) that aren't in github, so it grabs them from the latest DMD 
release.

BTW, This isn't just for Git DMD, it can also recompile release versions of 
DMD:

$ wget https://github.com/downloads/D-Programming-Language/dmd/dmd.2.057.zip
$ unzip dmd.2.057.zip



DVM will automatically detect whether you have a git-style or release-style 
project structure and act accordingly. Use DVM's -v (verbose) flag to see 
which it detects. It also detects D1 vs D2, so it can be used to compile 
D1/Phobos as well.

Be aware, it might have some trouble will really old releases of DMD 1 and 2 
due to changes in the project structure and/or makefiles. But anything 
remotely recent should work fine (if not, please file a bug).

If you're on Windows, it will automatically download and install DMC if DMC 
isn't detected on the PATH (you can also do it with "dvm install dmc"). But 
you may run into some "paths with spaces" trouble with the DMC toolchain 
that I wasn't able to fully track down, so if that happens, you should 
download DMC to a directory with no spaces:

$ dvm fetch dmc

and extract/install it manually.
Jan 06 2012
parent Jacob Carlborg <doob me.com> writes:
On 2012-01-06 23:38, Nick Sabalausky wrote:

 "Jacob Carlborg"<doob me.com>  wrote in message
 news:je7p3p$1pl1$1 digitalmars.com...

 I just released a new version of DVM, 0.4.0. The only thing new in this
 release in the "compile" command. This allows to compile DMD, druntime and
 Phobos from github. Create a folder, clone DMD, druntime and Phobos in the
 newly create folder, run "dvm compile folder" to compile everything. The
 compiler is placed in the DMD directory.


 In other words:

 $ git clone https://github.com/D-Programming-Language/dmd.git
 $ git clone https://github.com/D-Programming-Language/druntime.git
 $ git clone https://github.com/D-Programming-Language/phobos.git
 $ git clone https://github.com/D-Programming-Language/tools.git
 but this is optional
 $ dvm compile

 DMD32 D Compiler v2.0...
 ...etc...

 If you notice it downloading the latest DMD release before compiling,
 there's a reason for that: There are some files (from the bin and lib
 directories) that aren't in github, so it grabs them from the latest DMD
 release.

 BTW, This isn't just for Git DMD, it can also recompile release versions of
 DMD:

 $ wget https://github.com/downloads/D-Programming-Language/dmd/dmd.2.057.zip
 $ unzip dmd.2.057.zip



 DVM will automatically detect whether you have a git-style or release-style
 project structure and act accordingly. Use DVM's -v (verbose) flag to see
 which it detects. It also detects D1 vs D2, so it can be used to compile
 D1/Phobos as well.

 Be aware, it might have some trouble will really old releases of DMD 1 and 2
 due to changes in the project structure and/or makefiles. But anything
 remotely recent should work fine (if not, please file a bug).

 If you're on Windows, it will automatically download and install DMC if DMC
 isn't detected on the PATH (you can also do it with "dvm install dmc"). But
 you may run into some "paths with spaces" trouble with the DMC toolchain
 that I wasn't able to fully track down, so if that happens, you should
 download DMC to a directory with no spaces:

 $ dvm fetch dmc

 and extract/install it manually.


Thanks for the elaborated explanation.

-- 
/Jacob Carlborg
Jan 07 2012
prev sibling next sibling parent reply Don Clugston <dac nospam.com> writes:
On 06/01/12 22:29, Jacob Carlborg wrote:

 I just released a new version of DVM, 0.4.0. The only thing new in this
 release in the "compile" command. This allows to compile DMD, druntime
 and Phobos from github. Create a folder, clone DMD, druntime and Phobos
 in the newly create folder, run "dvm compile folder" to compile
 everything. The compiler is placed in the DMD directory.

 For installation instructions see: https://bitbucket.org/doob/dvm

 Changelog:

 Version 0.4.0
 New/Change Features
 * Added a "compile" command for compiling DMD, druntime and Phobos from
 github


I found that I needed to do:
cd .dvm
mkdir bin
before dvm install would work.
Jan 09 2012
parent reply Jacob Carlborg <doob me.com> writes:
On 2012-01-09 10:30, Don Clugston wrote:

 On 06/01/12 22:29, Jacob Carlborg wrote:

 I just released a new version of DVM, 0.4.0. The only thing new in this
 release in the "compile" command. This allows to compile DMD, druntime
 and Phobos from github. Create a folder, clone DMD, druntime and Phobos
 in the newly create folder, run "dvm compile folder" to compile
 everything. The compiler is placed in the DMD directory.

 For installation instructions see: https://bitbucket.org/doob/dvm

 Changelog:

 Version 0.4.0
 New/Change Features
 * Added a "compile" command for compiling DMD, druntime and Phobos from
 github


 I found that I needed to do:
 cd .dvm
 mkdir bin
 before dvm install would work.


Hmm, that's strange. On which platform? Is it when installing DVM itself 
or compilers?

-- 
/Jacob Carlborg
Jan 09 2012
parent reply Don Clugston <dac nospam.com> writes:
On 09/01/12 13:09, Jacob Carlborg wrote:

 On 2012-01-09 10:30, Don Clugston wrote:

 On 06/01/12 22:29, Jacob Carlborg wrote:

 I just released a new version of DVM, 0.4.0. The only thing new in this
 release in the "compile" command. This allows to compile DMD, druntime
 and Phobos from github. Create a folder, clone DMD, druntime and Phobos
 in the newly create folder, run "dvm compile folder" to compile
 everything. The compiler is placed in the DMD directory.

 For installation instructions see: https://bitbucket.org/doob/dvm

 Changelog:

 Version 0.4.0
 New/Change Features
 * Added a "compile" command for compiling DMD, druntime and Phobos from
 github


 I found that I needed to do:
 cd .dvm
 mkdir bin
 before dvm install would work.


 Hmm, that's strange. On which platform? Is it when installing DVM itself
 or compilers?


Linux64 (Ubuntu). When installing compilers.
Jan 13 2012
parent Jacob Carlborg <doob me.com> writes:
On 2012-01-13 16:53, Don Clugston wrote:

 On 09/01/12 13:09, Jacob Carlborg wrote:

 On 2012-01-09 10:30, Don Clugston wrote:

 On 06/01/12 22:29, Jacob Carlborg wrote:

 I just released a new version of DVM, 0.4.0. The only thing new in this
 release in the "compile" command. This allows to compile DMD, druntime
 and Phobos from github. Create a folder, clone DMD, druntime and Phobos
 in the newly create folder, run "dvm compile folder" to compile
 everything. The compiler is placed in the DMD directory.

 For installation instructions see: https://bitbucket.org/doob/dvm

 Changelog:

 Version 0.4.0
 New/Change Features
 * Added a "compile" command for compiling DMD, druntime and Phobos from
 github


 I found that I needed to do:
 cd .dvm
 mkdir bin
 before dvm install would work.


 Hmm, that's strange. On which platform? Is it when installing DVM itself
 or compilers?


 Linux64 (Ubuntu). When installing compilers.


Thanks, I'll take care of it.

-- 
/Jacob Carlborg
Jan 13 2012
prev sibling parent reply Robert Clipsham <robert octarineparrot.com> writes:
On 06/01/2012 21:29, Jacob Carlborg wrote:

 I just released a new version of DVM, 0.4.0. The only thing new in this
 release in the "compile" command. This allows to compile DMD, druntime
 and Phobos from github. Create a folder, clone DMD, druntime and Phobos
 in the newly create folder, run "dvm compile folder" to compile
 everything. The compiler is placed in the DMD directory.

 For installation instructions see: https://bitbucket.org/doob/dvm

 Changelog:

 Version 0.4.0
 New/Change Features
 * Added a "compile" command for compiling DMD, druntime and Phobos from
 github


When using a compiled dmd is there some way to allow dvm to manage it?

Even if it requires some manual intervention to set up, I'd like to be 
able to do:

$ dvm use master

Thanks,

-- 
Robert
http://octarineparrot.com/
Feb 01 2012
next sibling parent =?ISO-8859-1?Q?Alex_R=F8nne_Petersen?= <xtzgzorex gmail.com> writes:
On 01-02-2012 21:02, Robert Clipsham wrote:

 On 06/01/2012 21:29, Jacob Carlborg wrote:

 I just released a new version of DVM, 0.4.0. The only thing new in this
 release in the "compile" command. This allows to compile DMD, druntime
 and Phobos from github. Create a folder, clone DMD, druntime and Phobos
 in the newly create folder, run "dvm compile folder" to compile
 everything. The compiler is placed in the DMD directory.

 For installation instructions see: https://bitbucket.org/doob/dvm

 Changelog:

 Version 0.4.0
 New/Change Features
 * Added a "compile" command for compiling DMD, druntime and Phobos from
 github


 When using a compiled dmd is there some way to allow dvm to manage it?

 Even if it requires some manual intervention to set up, I'd like to be
 able to do:

 $ dvm use master

 Thanks,


+1!

--
- Alex
Feb 01 2012
prev sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2012-02-01 21:02, Robert Clipsham wrote:

 On 06/01/2012 21:29, Jacob Carlborg wrote:

 I just released a new version of DVM, 0.4.0. The only thing new in this
 release in the "compile" command. This allows to compile DMD, druntime
 and Phobos from github. Create a folder, clone DMD, druntime and Phobos
 in the newly create folder, run "dvm compile folder" to compile
 everything. The compiler is placed in the DMD directory.

 For installation instructions see: https://bitbucket.org/doob/dvm

 Changelog:

 Version 0.4.0
 New/Change Features
 * Added a "compile" command for compiling DMD, druntime and Phobos from
 github


 When using a compiled dmd is there some way to allow dvm to manage it?

 Even if it requires some manual intervention to set up, I'd like to be
 able to do:

 $ dvm use master

 Thanks,


I'm not sure I understand, DVM already handles a compiled DMD. That's 
the default, what it always have handled.

If you want to have a different name then you can just go ahead and 
renamed the necessary files and folders. What's needed for DVM to 
recognize a compiler:

In the ~/.dvm folder:

Folders:
* compilers/dmd-<name>
     |--- bin - standard DMD bin folder
     |--- src - standard DMD src folder
     |--- lib - standard DMD lib folder

Files:
* env/dmd-<name> - take a look at how the other env files look like
* bin/dmd-<name> - take a look at how the other bin files look like (not 
strictly necessary)
* compilers/dmd-<name>/bin/dmd.conf - standard DMD dmd.conf file except 
the "src" folder is just one level up instead of two:

[Environment]

DFLAGS=-I% P%/../src/phobos -I% P%/../src/druntime/import -L-L% P%/../lib

For Windows it should be similar, but instead of in ~/.dvm DVM is 
located somewhere else. I think it's in %APPDATA%\dvm which would be 
%USERPROFILE%\AppData\Roaming\dvm. Nick knows how it works on Windows 
better than I do.

-- 
/Jacob Carlborg
Feb 01 2012
parent "Nick Sabalausky" <a a.a> writes:
"Jacob Carlborg" <doob me.com> wrote in message 
news:jgde35$2h2t$1 digitalmars.com...

 For Windows it should be similar, but instead of in ~/.dvm DVM is located 
 somewhere else. I think it's in %APPDATA%\dvm which would be 
 %USERPROFILE%\AppData\Roaming\dvm. Nick knows how it works on Windows 
 better than I do.


It's in "%APPDATA%\dvm". On my computer, that resolves to "C:\Documents and 
Settings\Nick Sabalausky\Application Data\dvm", but naturally that's going 
to vary.

Everything else Jacob said about DVM's structure on Linux also applies to 
Windows DVM, too. The only differences are the content inside the scripts 
(and the fact that they're batch instead of linux shell, obviously).

I do like the idea of being able to do stuff like "dvm install ./myDMD mydmd 
&& dvm use mydmd" or "dvm use ./myDMD".
Feb 04 2012