Thread overview | ||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|
|
May 31, 2015 Entry point a la "git" or "go" | ||||
---|---|---|---|---|
| ||||
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 Re: Entry point a la "git" or "go" | ||||
---|---|---|---|---|
| ||||
Posted in reply to Andrei Alexandrescu | 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 Re: Entry point a la "git" or "go" | ||||
---|---|---|---|---|
| ||||
Posted in reply to weaselcat | 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 Re: Entry point a la "git" or "go" | ||||
---|---|---|---|---|
| ||||
Posted in reply to Andrei Alexandrescu | 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 Re: Entry point a la "git" or "go" | ||||
---|---|---|---|---|
| ||||
Posted in reply to Andrei Alexandrescu | 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...
|
June 01, 2015 Re: Entry point a la "git" or "go" | ||||
---|---|---|---|---|
| ||||
Posted in reply to Andrei Alexandrescu | 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.
|
June 01, 2015 Re: Entry point a la "git" or "go" | ||||
---|---|---|---|---|
| ||||
Posted in reply to weaselcat |
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
|
June 01, 2015 Re: Entry point a la "git" or "go" | ||||
---|---|---|---|---|
| ||||
Posted in reply to Andrei Alexandrescu | 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 |
June 03, 2015 Re: Entry point a la "git" or "go" | ||||
---|---|---|---|---|
| ||||
Posted in reply to Walter Bright | 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 ).
|
June 04, 2015 Re: Entry point a la "git" or "go" | ||||
---|---|---|---|---|
| ||||
Posted in reply to Idan Arye | 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.
|
Copyright © 1999-2021 by the D Language Foundation