dmd -unittest=<pattern> (same syntax as -i)

[Johannes Pfau]

Am Thu, 15 Mar 2018 23:21:42 +0000 schrieb Jonathan Marler:

> On Thursday, 15 March 2018 at 23:11:41 UTC, Johannes Pfau wrote:
>> Am Wed, 14 Mar 2018 14:22:01 -0700 schrieb Timothee Cour:
>>
>>> [...]
>>
>> And then we'll have to add yet another "-import" switch for DLL
>> support. Now we have 3 switches doing essentially the same: Telling the
>> compiler which modules are currently compiled and which modules are
>> part of an external library. Instead of just using the next best simple
>> solution, I think we should take a step back, think about this and
>> design a proper, generic solution.
>>
>> [...]
> 
> I had the same idea but mine was to add this metadata in the library
> file itself instead of having it as a separate file.

This is to some degree nicer, as it allows for self contained 
distribution. But then you have to support different library formats, 
it's more difficult to include support in IDEs and it's more difficult to 
extend the format.

> However, this
> design is "orthogonal" to -i= and -unittest=,  in both cases you may
> want to include/exclude certain modules regardless of whether or not
> they are in a library.

When would this be the case for -i? You never want to include modules in 
compilation which are in an external library you also link to, as you'll 
get duplicate symbol errors. I also don't see why you would want to 
exclude a module from compilation which is imported somewhere and not in 
any external library. Maybe to avoid generating the ModuleInfo and 
TypeInfo for 'header only' modules. But then you're breaking the 
assumption that typeid(X) works for any type, so excluding modules from 
compilation can't be a recommended practice.

For -unittest, I can see that you may sometimes want to test across 
library boundaries, but then you'd have to keep the tests out of the 
library anyway. I guess there could be cases where you want to instantiate 
a templated unittest for some type specializitaion, But I've never seen a 
real world use of that. Excluding local module from unittesting may be 
more useful, but I think version() and runtime selection of modules to be 
tested should cover basically all use cases.

Can you explain in some more detail what use cases you think of?

-- 
Johannes