There's this recent trend seen with git and go - all tooling is entered by a single command.

Are there advantages to doing the same for our toolchain? (Consider it'll include things such as dub, dfix, and dformat in the future.) Something like "dc", a program that parses the command line and dispatches it to the appropriate tool(s).

How would this add value to our toolchain?


Andrei

On Sunday, 31 May 2015 at 23:11:24 UTC, Andrei Alexandrescu wrote:
>
> How would this add value to our toolchain?
>
>
> Andrei

Having to install/manage less packages and executables. dtools provides 7 executable(on my distro) alone, not counting various compiler switches for profiling, etc. Then I have dcd, dscanner, dfmt, etc

being able to just provide it all under one executable simplifies installation and makes package management easier.

On 5/31/15 4:28 PM, weaselcat wrote:
> On Sunday, 31 May 2015 at 23:11:24 UTC, Andrei Alexandrescu wrote:
>>
>> How would this add value to our toolchain?
>>
>>
>> Andrei
>
> Having to install/manage less packages and executables.

git distributes a bunch of executables. -- Andrei

On Sunday, 31 May 2015 at 23:31:00 UTC, Andrei Alexandrescu wrote:
> On 5/31/15 4:28 PM, weaselcat wrote:
>> On Sunday, 31 May 2015 at 23:11:24 UTC, Andrei Alexandrescu wrote:
>>>
>>> How would this add value to our toolchain?
>>>
>>>
>>> Andrei
>>
>> Having to install/manage less packages and executables.
>
> git distributes a bunch of executables. -- Andrei

do you mean as a default installation?

pacman -Ql git | grep bin
git /usr/bin/
git /usr/bin/git
git /usr/bin/git-cvsserver
git /usr/bin/git-receive-pack
git /usr/bin/git-shell
git /usr/bin/git-upload-archive
git /usr/bin/git-upload-pack
git /usr/bin/gitk

On Sunday, 31 May 2015 at 23:11:24 UTC, Andrei Alexandrescu wrote:
> There's this recent trend seen with git and go - all tooling is entered by a single command.
>
> Are there advantages to doing the same for our toolchain? (Consider it'll include things such as dub, dfix, and dformat in the future.) Something like "dc", a program that parses the command line and dispatches it to the appropriate tool(s).
>
> How would this add value to our toolchain?
>
>
> Andrei

This is creating a "namespace", which has all sorts of benefits:

1) Easier help - `dc --help` shows basic description of all subtools.

2) Better names - since all tools reside in the `dc` command anyways they can have names based on what they do and not some acronym or a made-up project name. Instead of `dub` and `rdmd` we can have `dc build` and `dc run-script` - which convey what they do right away.

3) Containment - since all tools are under `dc`, and assuming `dc` can have some general-purpose flags, it's easier to build wrappers around it. You've mentioned git - there is a Git plugin for Vim called Fugitive that in addition for implementing commands that give special treatment wrapping to some Git commands, also offers the general `:Git` command, that can run any Git command you like and sets the general `git` flags to play better with Vim. It can do so because all Git commands start with `git `. Not sure yet how this property of single-entry-point-tool-chain will benefit D though - it depends on what the general flags for `dc` will be...

On 5/31/2015 4:11 PM, Andrei Alexandrescu wrote:
> Something like
> "dc", a program that parses the command line and dispatches it to the
> appropriate tool(s).

dc is taken on linux. dlang might be better.

On Sun, 31 May 2015 23:34:42 +0000
weaselcat via Digitalmars-d <digitalmars-d@puremagic.com> wrote:

> On Sunday, 31 May 2015 at 23:31:00 UTC, Andrei Alexandrescu wrote:
> > On 5/31/15 4:28 PM, weaselcat wrote:
> >> On Sunday, 31 May 2015 at 23:11:24 UTC, Andrei Alexandrescu wrote:
> >>>
> >>> How would this add value to our toolchain?
> >>>
> >>>
> >>> Andrei
> >>
> >> Having to install/manage less packages and executables.
> >
> > git distributes a bunch of executables. -- Andrei
> 
> do you mean as a default installation?
> 
> pacman -Ql git | grep bin
> git /usr/bin/
> git /usr/bin/git
> git /usr/bin/git-cvsserver
> git /usr/bin/git-receive-pack
> git /usr/bin/git-shell
> git /usr/bin/git-upload-archive
> git /usr/bin/git-upload-pack
> git /usr/bin/gitk

Thaats not all, there are lots of others in /usr/lib/git-core pacman -Ql git | grep /usr/lib/git-core

On 2015-06-01 01:11, Andrei Alexandrescu wrote:
> There's this recent trend seen with git and go - all tooling is entered
> by a single command.
>
> Are there advantages to doing the same for our toolchain? (Consider
> it'll include things such as dub, dfix, and dformat in the future.)
> Something like "dc", a program that parses the command line and
> dispatches it to the appropriate tool(s).
>
> How would this add value to our toolchain?

I like the idea. Currently there are a couple flags that are kind of namespaced example:

  -D             generate documentation
  -Dddocdir      write documentation file to docdir directory
  -Dffilename    write documentation file to filename

I have thought of moving the doc generating to a separate tool/executable, to allow better names for these flags and avoid cluttering the compiler with flags. But making it into an action/command on the compiler instead would be even better.

-- 
/Jacob Carlborg

On Monday, 1 June 2015 at 00:45:40 UTC, Walter Bright wrote:
> On 5/31/2015 4:11 PM, Andrei Alexandrescu wrote:
>> Something like
>> "dc", a program that parses the command line and dispatches it to the
>> appropriate tool(s).
>
> dc is taken on linux. dlang might be better.

this would also be nice for beginners as you could do just "dlang help" and you would get an overview over what tools are actually available.

aproposez the term dlang : it would be nice if people would use this more consistently so that google picks it up. i still often get "autoswitched" to the golang term.
One could even go further and engineer this (some people would call it SEO ;) )  by embedding it somewhere where everybody needs to use it (ideas: rename dub.json to dub.dlang, accept .dlang as file ending, embed it somehow into the documentation system, alias std. with dlang. etc ).

On Sunday, 31 May 2015 at 23:56:42 UTC, Idan Arye wrote:
> On Sunday, 31 May 2015 at 23:11:24 UTC, Andrei Alexandrescu wrote:
>> There's this recent trend seen with git and go - all tooling is entered by a single command.
>>
>> Are there advantages to doing the same for our toolchain? (Consider it'll include things such as dub, dfix, and dformat in the future.) Something like "dc", a program that parses the command line and dispatches it to the appropriate tool(s).
>>
>> How would this add value to our toolchain?
>>
>>
>> Andrei
>
> This is creating a "namespace", which has all sorts of benefits:
>
> 1) Easier help - `dc --help` shows basic description of all subtools.
>
> 2) Better names - since all tools reside in the `dc` command anyways they can have names based on what they do and not some acronym or a made-up project name. Instead of `dub` and `rdmd` we can have `dc build` and `dc run-script` - which convey what they do right away.
>
> 3) Containment - since all tools are under `dc`, and assuming `dc` can have some general-purpose flags, it's easier to build wrappers around it. You've mentioned git - there is a Git plugin for Vim called Fugitive that in addition for implementing commands that give special treatment wrapping to some Git commands, also offers the general `:Git` command, that can run any Git command you like and sets the general `git` flags to play better with Vim. It can do so because all Git commands start with `git `. Not sure yet how this property of single-entry-point-tool-chain will benefit D though - it depends on what the general flags for `dc` will be...

It would also make it easier to integrate the tools into an IDE. Yeah, definitely, it'd be nice to have a one-stop executable (similar to dub). I like `dlang`. E.g. to build with GDC:

dlang build release gdc

Maybe (on Windows) an option for DLLs and linking to C libraries would be nice too.