Named unittests and __traits(getModules)
Andre Pany
andre at s-e-a-p.de
Fri May 24 18:53:34 UTC 2019
On Friday, 24 May 2019 at 15:32:15 UTC, Jacob Carlborg wrote:
> On 2019-05-23 22:42, Andre Pany wrote:
>
>> One thing I do not understand. Once module A, which contains
>> the new traits, is compiled using separate compilation, the
>> list of found modules is fixed. If now new module B is added,
>> nothing will cause a rebuild of A and therefore the list of
>> found modules is incomplete.
>>
>> This can of course be solved by telling the user to not use
>> separate compilation, which might be a fair tradeoff, I am not
>> sure.
>
> It works with separate compilation if the unit tests are
> collected into a global variable. Here's an example using the
> existing __traits(allMembers):
>
> $ cat main.d
> module bar;
>
> extern (C) __gshared string[] members;
>
> void main()
> {
> import foo;
>
> members ~= [__traits(allMembers, bar)];
> foobar();
> assert(members == ["object", "members", "main", "object",
> "members", "foobar"]);
> }
>
> $ cat foo.d
> module foo;
>
> extern (C) extern __gshared string[] members;
>
> void foobar()
> {
> members ~= [__traits(allMembers, foo)];
> }
>
> $ dmd -c foo.d && dmd foo.o -run main.d
>
> The assertion passes as expected.
Maybe my understanding is wrong. As far as I understand, your
example only works as long as foo.d is compiled first and and
main.d last. The order is guaranteed by the import foo statement.
But if now use __traits(getModules) in main.d and compile with
this command:
dmd -c main.d && dmd main.o -run foo.d
I assume it won't work anymore.
The order of compilation will then matter and I do not how you
can ensure the file containing the __traits(getModules) is always
compiled as last.
Kind regards
Andre
More information about the Digitalmars-d
mailing list