I have a macro that expands into a module definition. The use case is that we take a testcase defined in one elixir module (parent) and modify some parameters and generate a new module that calls parent where needed but as a new, separate testcase. (This works fine.)

Files then look like this:

require ParametrizedTestcase

ParametrizedTestcase.new(<keyword list>) # let's call this B

ParametrizedTestcase.new(<keyword list>) # let's call this C

So this would for example create new variation B and C of an original testcase A. Or C could even be a variation of B.

When trying to extend it I run into limits defined by when elixir expands macros vs when the modules are compiled.

It’s fine if C statically calls B in its implementation.

It’s fine if C checks in the macro itself if a function in a generated module is exported if and only if that module is not in the same compilation unit/file. (B must be moved.)

The check for a function being exported simply returns false if C tries, in the macro, to check if something is defined in B.

I assume this is because all macros in the compilation unit are expanded together before the modules are compiled.

It seems separating the calls into separate files would avoid this, but right now I have a lot of these testcases organized by files acting as categories, something my users expect. (The joys of legacy.)

My questions are:

1. Is there a way to enforce compilation of what has been expanded so far before continuing? (Like: I need B to be compiled before C expands.)

OR

2. Is there a way to prevent the user of the API to invoke the same macro twice in the same compilation unit to enforce splitting invocations over separate files?

The rationale for 2. would be that if I cannot make this work in one file, I want to prevent the possibility of generating erroneous definitions when users revert to adding multiple definitions in one file again. If the macro’s correctness depends on B being compiled before C is expanded, I want to guarantee there’s no two ways to approach this.

Thank you!