Glad to announce first version of https://github.com/mihails-strasuns/dc suitable for public destruction. It is a small utility originally created to fulfill similar purpose to existing `install.sh` script but also with Windows support.

https://github.com/mihails-strasuns/dc/releases/tag/v1.0.0

It is provided as an independent statically linked binary which creates and maintain own toolchain directory with `bin`/`lib`/`imports` sub-directories and allows to quickly switch between compiler versions.

Two main use cases:

- Cross-platform CI, being able to just say `dc use ldc-1.14.0` in your test spec for both Linux and Windows
- Quicky and dirty switching between compiler versions on development machines.

Contrary to `install.sh` and DVM approach, DC changes active compiler globally instead of a current shell context only. This done intentionally to simplify integration with IDEs and other non-CLI tools - though temporary shell-only switching is also planned once I come with a decent design.

It is also possible (and encouraged) to put own development tools and static libraries in toolchain `bin` and `lib` folders accordingly to make them easily available without doing any system install.

Right now the tool is in "works for me" stage, any feedback is welcome.

On 2019-03-31 13:39, Mihails wrote:

> Contrary to `install.sh` and DVM approach, DC changes active compiler globally instead of a current shell context only.

FYI, DVM allows to set the globally active compiler as well, using "dvm use <version> -d". This is known as the default compiler.

These days I don't use the "use" command that often because the compiler is more stable, less reason to pin a project to a given compiler version. Also most of my projects work with the latest version of the compiler.

> This done intentionally to simplify integration with IDEs and other non-CLI tools - though temporary shell-only switching is also planned once I come with a decent design.

DVM has two wrappers that helps with editor and IDE integration in the form of "dvm-current-dc", which always points to the currently active compiler (which actually more is the latest chosen compiler) and "dvm-default-dc" which always points to the default, or global, compiler. Both of these live in "~/.dvm/bin" (on Posix). You can point your editor or IDE to the full path of one of these two wrappers. DVM also provides wrappers for each compiler version in the form of "dmd-<version>" also located in "~/.dvm/bin", if you want to explicitly invoke a given version without switching the active version.

-- 
/Jacob Carlborg

On 2019-03-31 13:39, Mihails wrote:
> Glad to announce first version of https://github.com/mihails-strasuns/dc suitable for public destruction. It is a small utility originally created to fulfill similar purpose to existing `install.sh` script but also with Windows support.

It's kind of funny that you decided to release this exactly the same day as I planned to release a new version of DVM [1] :)

[1] https://forum.dlang.org/post/q7r3i5$2cdh$1@digitalmars.com

-- 
/Jacob Carlborg

On 2019-03-31 13:39, Mihails wrote:
> Glad to announce first version of https://github.com/mihails-strasuns/dc suitable for public destruction.

As for the destruction:

* Saying it's cross-platform and only supporting two platforms is stretching it a bit.

* Using the "tar" [1] command line tool is cheating :). It might not be available inside a Docker container, for example.

* Regarding `currentProcessBinary` [2]. Phobos has a function for that, which is cross-platform [3].

[1] https://github.com/mihails-strasuns/dc/blob/f314916b04879604e3f8629534a3cf2b1bd4d92c/source/dc/platform/posix.d#L78-L81

[2] https://github.com/mihails-strasuns/dc/blob/f314916b04879604e3f8629534a3cf2b1bd4d92c/source/dc/utils/path.d#L46

[3] https://dlang.org/phobos/std_file.html#.thisExePath

-- 
/Jacob Carlborg

On Sunday, 31 March 2019 at 19:15:20 UTC, Jacob Carlborg wrote:
> It's kind of funny that you decided to release this exactly the same day as I planned to release a new version of DVM [1] :)
>
> [1] https://forum.dlang.org/post/q7r3i5$2cdh$1@digitalmars.com

Nice, I must admit I have had my mind set about DVM as something that has existed for years and wasn't quite the right thing. Had no idea you kept improving it lately.

Well, it is not a big enough project for me to be sad about the duplicate effort :)

On 2019-04-01 12:31, Mihails wrote:

> Nice, I must admit I have had my mind set about DVM as something that has existed for years and wasn't quite the right thing. Had no idea you kept improving it lately.

Yeah, I thought it was time to fix one or two bugs.

-- 
/Jacob Carlborg

On Monday, 1 April 2019 at 17:35:38 UTC, Jacob Carlborg wrote:
> On 2019-04-01 12:31, Mihails wrote:
>
>> Nice, I must admit I have had my mind set about DVM as something that has existed for years and wasn't quite the right thing. Had no idea you kept improving it lately.
>
> Yeah, I thought it was time to fix one or two bugs.

Appreciated!

Once we take D into production I plan to integrate a tool like dvm or dc into our build system for two main reasons:

1) to have reproducible historical builds, being able to check out a revision from a year or more ago and compile it without deprecation warnings or errors that we did not have back then, and including any bugs that may have been present in e.g. phobos.

2) being able to prepare the code base for a new compiler release (or brand), push it, so that thereafter all developers and CI systems start using it without further thought or administration.

This is an important gear in the drivetrain that will allow us to maintain a "Please break our code!" mentality so that the language can continue to get better and better without us being left behind.

So thank you.

Bastiaan.

On 2019-04-02 13:49, Bastiaan Veelo wrote:

> So thank you.

You're welcome :)

-- 
/Jacob Carlborg