www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Entry point a la "git" or "go"

reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
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
May 31 2015
next sibling parent reply "weaselcat" <weaselcat gmail.com> writes:
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.
May 31 2015
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
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
May 31 2015
parent reply "weaselcat" <weaselcat gmail.com> writes:
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
May 31 2015
parent Daniel =?UTF-8?B?S296w6Fr?= via Digitalmars-d writes:
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
May 31 2015
prev sibling next sibling parent reply "Idan Arye" <GenericNPC gmail.com> writes:
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...
May 31 2015
parent "Chris" <wendlec tcd.ie> writes:
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.
Jun 04 2015
prev sibling next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
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.
May 31 2015
parent "y" <dlang srtnwz.com> writes:
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 ).
Jun 03 2015
prev sibling parent Jacob Carlborg <doob me.com> writes:
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
Jun 01 2015