Almost since its birth, the D IDE Coedit has a feature allowing to run or test a single module. In this case, the IDE passed automatically the version identifer
`runnable_module`. Since today i use new identifiers and i suggest you to use them too, to provide a more consistent D environment, in case the editor you develop propose a similar feature of course (I don't know the other IDEs/editors FYI).


`single_module`
===============

Should be set when a single module is compiled and executed. (add -version=single_module to the command line)


`run_single_module`
===================

Should be set when a single module is compiled and executed but not if -unittest
is also set. (add -version=run_single_module to the command line)

`test_single_module`
====================

Should be set when a single module is compiled and executed and if -unittest is also set. (add -version=test_single_module to the command line)


So that finally there will always be 2 identifiers set.
I'll also propose to the DUB developers to add this when a DUB script is executed.

Am Wed, 28 Mar 2018 09:08:07 +0000
schrieb Basile B. <b2.temp@gmx.com>:

> Almost since its birth, the D IDE Coedit has a feature allowing
> to run or test a single module. In this case, the IDE passed
> automatically the version identifer
> `runnable_module`. Since today i use new identifiers and i
> suggest you to use them too, to provide a more consistent D
> environment, in case the editor you develop propose a similar
> feature of course (I don't know the other IDEs/editors FYI).
> 
> 
> `single_module`
> ===============
> 
> Should be set when a single module is compiled and executed. (add -version=single_module to the command line)
> 
> 
> `run_single_module`
> ===================
> 
> Should be set when a single module is compiled and executed but
> not if -unittest
> is also set. (add -version=run_single_module to the command line)
> 
> `test_single_module`
> ====================
> 
> Should be set when a single module is compiled and executed and if -unittest is also set. (add -version=test_single_module to the command line)
> 
> 
> So that finally there will always be 2 identifiers set.
> I'll also propose to the DUB developers to add this when a DUB
> script is executed.

I think this needs a better communication channel. Somewhere where e.g. all build tool devs or all Linux devs look and discuss the small things which are then pinned or wikified. Here I fear call outs like this one often go unnoticed.

Maybe a Trello group of all build tool devs + the Wiki
would work better? This is the one for Dlang:
https://trello.com/dlang
But that focuses on the language, not so much the eco system
and I'm worried that it would become like the news group if
everyone's affairs were discussed there.
Similarly for Linux there is always good questions about how
to work around issues with ld.gold or how to name directories
so the user experience is similar on as many OSs as possible
without messing with the idiosyncrasies of any.
There /is/ a lot of overlap though when you discuss how a
build tool would integrate with the package manager for
example.

-- 
Marco

On Monday, 23 April 2018 at 08:16:45 UTC, Marco Leise wrote:
> Am Wed, 28 Mar 2018 09:08:07 +0000
> schrieb Basile B. <b2.temp@gmx.com>:
>
>> Almost since its birth, the D IDE Coedit has a feature allowing
>> to run or test a single module. In this case, the IDE passed
>> automatically the version identifer
>> `runnable_module`. Since today i use new identifiers and i
>> suggest you to use them too, to provide a more consistent D
>> environment, in case the editor you develop propose a similar
>> feature of course (I don't know the other IDEs/editors FYI).
>> 
>> 
>> `single_module`
>> ===============
>> 
>> Should be set when a single module is compiled and executed. (add -version=single_module to the command line)
>> 
>> 
>> `run_single_module`
>> ===================
>> 
>> Should be set when a single module is compiled and executed but
>> not if -unittest
>> is also set. (add -version=run_single_module to the command line)
>> 
>> `test_single_module`
>> ====================
>> 
>> Should be set when a single module is compiled and executed and if -unittest is also set. (add -version=test_single_module to the command line)
>> 
>> 
>> So that finally there will always be 2 identifiers set.
>> I'll also propose to the DUB developers to add this when a DUB
>> script is executed.
>
> I think this needs a better communication channel. Somewhere where e.g. all build tool devs or all Linux devs look and discuss the small things which are then pinned or wikified. Here I fear call outs like this one often go unnoticed.
>
> Maybe a Trello group of all build tool devs + the Wiki
> would work better? This is the one for Dlang:
> https://trello.com/dlang
> But that focuses on the language, not so much the eco system
> and I'm worried that it would become like the news group if
> everyone's affairs were discussed there.
> Similarly for Linux there is always good questions about how
> to work around issues with ld.gold or how to name directories
> so the user experience is similar on as many OSs as possible
> without messing with the idiosyncrasies of any.
> There /is/ a lot of overlap though when you discuss how a
> build tool would integrate with the package manager for
> example.

Yeah i've seen the other message in d.general and hesitated answering "i don't know" (if this is a good idea). I'm myself very rarely in contact with other IDE developers and about compilers never, i just adapt my IDE to how things are. Better experiences so far has been actually with DUB developers who added 2 or three times things useful for me, which was nice.

That being said i'll follow, if this board comes to birth.

Am Mon, 23 Apr 2018 14:07:06 +0000
schrieb Basile B. <b2.temp@gmx.com>:

> Yeah i've seen the other message in d.general and hesitated answering "i don't know" (if this is a good idea). I'm myself very rarely in contact with other IDE developers and about compilers never, i just adapt my IDE to how things are. Better experiences so far has been actually with DUB developers who added 2 or three times things useful for me, which was nice.
> 
> That being said i'll follow, if this board comes to birth.

I've been handling it the same. Just now and then there are
little things that we could all agree on, like that standard
import path on Linux and make things easier for everyone.
The reception overall was rather "meh", so I wont look further
into it for now.

-- 
Marco