dlang-workspace is a folder/config structure that allows you to easily contribute to the D projects (dmd, druntime, phobos) while not tampering with (or relying on) your standard installation.

It's been tested on OSX and Debian, more testing and Windows support are appreciated.

    https://github.com/carlor/dlang-workspace

Thanks for checking it out.

NMS

-- README.md pasted here --

`dlang-workspace` contains the basic configurations for hacking on your own
fork of `dmd`, `druntime`, and `phobos` on nix systems, while not conflicting
with your installed stable version.

To install:

    $ git clone git://github.com/carlor/dlang-workspace.git dlang
    $ cd dlang/
    $ git clone <dmd,      the central repo or your fork>
    $ git clone <druntime, the central repo or your fork>
    $ git clone <phobos,   the central repo or your fork>

Now, you can run the `posix/gen.sh` script to build all repositories. You can
specify what item specifically to build (`dmd`, `phobos`, or `druntime`) as a
parameter to `gen.sh`.

It makes an executable which links to your fork of druntime/phobos called `wbd`.
You guess the acronym (hint: MRI).

You can specify what item specifically to build (`dmd`, `phobos`, or `druntime`)
as a parameter to `gen.sh`.

Everything applicable is released under the GPLv3.

Platform Support
----------------
This has been tested on OSX, Debian, and Ubuntu, and works without a standard
install of the D system.

It doesn't work on Windows; pull requests to add support for that, or anything
else, are appreciated.

> To install:
>
>     $ git clone git://github.com/carlor/dlang-**workspace.git<http://github.com/carlor/dlang-workspace.git>dlang
>     $ cd dlang/
>     $ git clone <dmd,      the central repo or your fork>
>     $ git clone <druntime, the central repo or your fork>
>     $ git clone <phobos,   the central repo or your fork>
>
> Now, you can run the `posix/gen.sh` script to build all repositories. You
> can
> specify what item specifically to build (`dmd`, `phobos`, or `druntime`)
> as a
> parameter to `gen.sh`.
>
> It makes an executable which links to your fork of druntime/phobos called
> `wbd`.
> You guess the acronym (hint: MRI)
>

Works like a charm here! (Kubuntu). You code builds dmd and the rest flawlessly and the resulting executable works OK. Great! Building and rebuilding was exactly what stopped me from using the lastest DMD. Now, I can test my projects with both 2.060 and the latest git HEAD.

Eh, compilation is 10% faster with 2.061 than with 2.060! And all unit tests pass, woo hoo!

Thanks a lot Nathan!

On Thursday, 6 December 2012 at 20:31:03 UTC, Nathan M. Swan wrote:
>     $ git clone git://github.com/carlor/dlang-workspace.git dlang
>     $ cd dlang/
>     $ git clone <dmd,      the central repo or your fork>
>     $ git clone <druntime, the central repo or your fork>
>     $ git clone <phobos,   the central repo or your fork>


Highly, highly recommend using submodules so this becomes

$ git submodule init
$ git submodule update

Everyone will still be able to update the folders to the latest in the same manner as currently done. And it will have the benefit of having a selection of commits that are known to work together and with the provided tools.

$ git submodule add repo dir
...
...

This will also be most appropriate if it gets official claim.

Thanks! This is great! :)

I've tried it on Scientific Linux 6.1.

On 12/06/2012 12:31 PM, Nathan M. Swan wrote:

> Now, you can run the `posix/gen.sh` script to build all repositories.

In my case, posix/gen.sh was not executable. I did this:

$ chmod a+x posix/gen.sh

wbd was built successfully (with the expected deprecation warnings from Phobos).

One thing I've noticed is that I could compile programs only if wbd has been started from within this directory. No big deal...

Ali

On 2012-12-07 01:24, Jesse Phillips wrote:

> $ git submodule init
> $ git submodule update

Or just one command:

$ git submodule update --init

-- 
/Jacob Carlborg

In response to an email Nathan wrote:

>Submodules seem to be meant for including a project you're not working on, just >referencing (i.e. a library).
>
>dlang-workspace is built for contributors for D in mind, so there will be a lot >of forking/branching, something submodules to not handle well.
>
>I'm not experienced in this though, so tell if I'm wrong.
>
>Thanks,
>NMS

Wrong, all submodules will do is store the hash for each repo. This is really good because even with projects you work on you'll require all three (Phobos, druntime, dmd) to be in a specific version that is compatible with your changes. It does mean that by default you are unlikely to check out the latest of all three (since I doubt you'll be updating the repo for that.

However, consider the developer here. They are making some changes, then need to test a pull request, this pull request uses a newer version of dmd. They will then be able to commit all their changes including the current commit of the dependent DMD, checkout the new development branch with whatever version of dmd is needed. When testing is done they checkout their branch update the submodules and continue  their work updating and testing dmd when ready for the pull request.

It does actually make it more complicated as to get the latest it would be:
$ git submodule update --init
$ cd dir
$ git --rebase pull
...

But really a utility can have that: ./latest.sh