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

Johannes Pfau nospam at example.com
Thu Mar 15 23:11:41 UTC 2018


Am Wed, 14 Mar 2018 14:22:01 -0700 schrieb Timothee Cour:

> would a PR for `dmd -unittest=<pattern> (same syntax as -i)` be welcome?
> wouldn't that avoid all the complicatiosn with version(StdUnittest) ?
> eg use case:
> 
> # compile with unittests just for package foo (excluding subpackage
> foo.bar)
> dmd -unittest=foo -unittest=-foo.bar -i main.d

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.

Then instead of having to use up to 6 flags(1) to link a library we can 
use one and even end up with better user experience than what we have now 
or what C++ provides:

(1)
dmd -I /libfoo -L-Bstatic -L-llibfoo -i main.d -unittest main.d -import 
libfoo*

(2)
dmd -library=foo:static

The key here is to realize that all the necessary information for 
unittests, DLL imports, library linking and automatically finding source 
dependencies is knowing the library layout. The compiler needs to know 
which modules are externally in libraries and which are currently build*.

In order to achieve this, we should define a standardized library 
metadata file which lists:
* source files belonging to that library (replaces -i and -import and -  
  unittest=)
* (relative) source path (to replace -I)
* library name (to replace -L)
* optional linker flags

Some of these are actually covered by the pkg-config format which is 
extensible and already used by meson when building D projects. Then we 
simply need the compiler to parse these files (optionally also generate 
them) and we can have a much cleaner user experience.

As these files are the extensible, you can also add documentation URIs 
for example. In the end, you could simply open your IDE, browse a list of 
libraries (even online, if we map names 1:1 to dub names), select the 
library and the IDE could provide documentation. The compiler then 
transparently handles includes, library linking, ....

I think I'll start writing a DIP for this on Sunday but given the state 
of the DIP queue it'll take some time till this will get reviewed. 


* (There actually may be some corner cases where you may want to exclude 
unittests for some modules which are actually compiled. I think version 
statements are fine for that usecase. We should try to find other special 
use cases and see whether this simple, generic approach works for all of 
them.)

-- 
Johannes


More information about the Digitalmars-d mailing list