-
Notifications
You must be signed in to change notification settings - Fork 246
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add Core Erlang support. #384
base: master
Are you sure you want to change the base?
Add Core Erlang support. #384
Conversation
Support the compilation of .core files in the directory for applications which use source code authored directly in Core Erlang.
In the case of a beam called Coq.Arith.EqNat, which will be called directly in the Core Erlang like call 'Coq.Arith.EqNat':'beq_nat', don't put into a subdirectory or the emulator will not be able to find it.
@cmeiklejohn what do you think about attempting to make a unit test for this? |
I pushed a test that writes out a Erlang |
@richcarl Any thoughts here? |
If you tell eunit to test a module x, it will also look for a module x_tests, but if it doesn't find one it should not be a problem as it should simply run only the test functions found in x itself. What's happening in your case? |
it's looking for a test module generated from the compilation of the core erlang module -- which it doesn't find and I gives me the following output:
|
I haven't had time to check out the code and try it, but it seems pretty strange. Somehow eunit gets passed the atom 'myapp_mycoremod' as a test to be executed, perhaps from a generator function. But I can't see anything in your commit that would cause that to happen. |
Tried to see what's going on, but I think it's rebar scanning for files on its own, and somehow ends up finding this module although it for some reason can't be found in the code path when it tries to run it. Perhaps a race condition where the teardown has already removed the .beam file when it comes to the point where it tries to run the tests for the module that it found. |
For protocol buffer files, when there were gpb options to alter the module name with prefix or suffix, recompilation was not properly detected. This is now fixed. (Issue basho#384). Properly detecting change meant moving from rebar_base_compiler, so it also meant processing protocol buffer files in sequence instead of in parallel.
For protocol buffer files, when there were gpb options to alter the module name with prefix or suffix, recompilation was not properly detected. This is now fixed. (Issue basho#384). Use the rebar_base_compiler's ability to specify both source and target file names, to be able to also support prefixes. This also introduces a call to gpb_compile:format_error, so the xref recipe needs to be updated to ignore it, to avoid false errors.
Support the compilation of .core files in the directory for applications
which use source code authored directly in Core Erlang.