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