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