Oliver
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:
- 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
- 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!
Trending in Questions
Other Trending Topics
Categories:
Sub Categories:
Forums
Popular Tags
- #ecto
- #liveview
- #troubleshooting
- #learning-elixir
- #library
- #deployment
- #erlang
- #testing
- #genserver
- #mix
- #absinthe
- #remote-other
- #otp
- #plug
- #how-to-question
- #macros
- #postgres
- #elixirconf
- #channels
- #exunit
- #discussion
- #code-sync
- #podcasts
- #javascript
- #onsite
- #dialyzer
- #docker
- #authentication
- #umbrella
- #full-time-contract
- #podcasts-by-brainlid
- #ecto-query
- #elixirconf-us
- #blog-post
- #ai
- #elixir-ls
- #phoenix_html
- #iex
- #graphql
- #genstage
- #websockets
- #supervisor
- #advent-of-code
- #distillery
- #processes
- #api
- #forms
- #hex
- #security
- #metaprogramming










Showing Posts 1 to 5- Show Best Posts
- Show All (oldest first)
- Show All (newest first)
LostKobrakai
The unit of compilation is files not modules afaik. There‘s no guarantee that there‘s modules in an elixir file, nor how many.
mudasobwa
Assuming it expands to
defmodule, I believeModule.create/3instead would do.mudasobwa
Sure. Launch a custom
Mix.Task.Compilerand spawn a process in itsrun/1callback implementation. Then tracedef trace({remote, meta, YourUsedMod, :__using__, 1}, env)and keep track of what has been already done on that matter.Oliver
@mudasobwa This is indeed the solution I was seeking. Thank you very much!
I did some experiments with it and it does what I want.
I would have just never guessed that from the documentation.
While I suspected it actually did what I wanted because it returned bytecode, it actually doesn’t mention it.
Something along the lines of
"It also instantly compiles and loads the module."would be a great addition there.Definitely a really cool thing!
mudasobwa
Cool. Then please don’t mind to open a PR to Elixir core adding this wording to documentation.