Erlang 'core' file compilation with mix

So apparently mix only supports yrl, xrl and erl file extensions, even though the core file extension is supported natively by erlc and compiled straight to beam files, just like an erl file, and I have an old erlang thing that is spitting out core files that I have to erlc src/blah.core && mv blah.beam _build/dev/lib/my_server/ebin/ on every-single-rebuild, which quickly became irritating. Is there a reason that mix is not supporting erlang standard core files and how do you get mix to work with them? I was not able to find any mix compiler at hex.pm for them (even though it would just be the normal erlang one that is built into mix itself quite literally just copied verbatum with a single :from_core option passed to:
https://github.com/elixir-lang/elixir/blob/master/lib/mix/lib/mix/tasks/compile.erlang.ex#L98
when the file extension is core instead of erl a few lines above.

This sounds like a lot of code just to copy and keep in sync for a two line change (or a few dozen changes if I want to make its options distinct from normal ‘erl’ files, which you’d never want to do anyway as they are just erl files in a more uniform format). I did submit an issue request as this really seemed like a bug in mix at first, but the response given was “We support only .erl, .xrl and .yrl extensions. Everything else requires a custom compiler.”, which is odd considering it ‘is’ just a processed erl file. And considering the certainty of the response of ‘We support only’ that rules out a PR…

So, ignoring the above… ^.^

  1. Why does the erlang compiler in mix not support both erlang formats?
  2. Where is a compiler plugin for the core format as there does not seem to be one on hex.pm.
  3. And is it really worth duplicating the entire mix erlang compiler thing just to change a couple lines when it could easily support both? >.>

An example, in a new mix project I put this in the file at ./src/tester.core:

module 'tester' ['add'/2,
                 'module_info'/0,
                 'module_info'/1]
    attributes []
'add'/2 =
    %% Line 8
    fun (_cor1,_cor0) ->
        call 'erlang':'+'
            (_cor1, _cor0)
'module_info'/0 =
    fun () ->
        call 'erlang':'get_module_info'
            ('tester')
'module_info'/1 =
    fun (_cor0) ->
        call 'erlang':'get_module_info'
            ('tester', _cor0)
end%

And try running it:

$ iex -S mix
Eshell V8.2  (abort with ^G)
Interactive Elixir (1.4.0) - press Ctrl+C to exit (type h() ENTER for help)
iex> :tester.add(1,2)
** (UndefinedFunctionError) function :tester.add/2 is undefined (module :tester is not available)
    :tester.add(1, 2)

So… yeah, I then compile it manually using the same call from mix for consistency and then it works:

iex> :compile.file('./src/tester.core', [:from_core])
{:ok, :tester}
iex> :tester.add(1,2)
3

It is very odd for a base erlang file not to be supported natively… o.O

Such a horrible horrible hack, but I fixed it in https://github.com/OvermindDL1/mix_compile_erlang_core and if that is depended on then it will overwrite the existing elixir erlang compile package so it supports erl and core erlang files all at once. At least can compile it now without manually copying things around, for the price of a warning: redefining module on initial dependency compilation… >.>

Horrible horrible hack, should be done right in the mix.task.compile.erlang task itself… >.>

EDIT: Not wanting to put on hex.pm, I really do not want to be forced to keep it in sync with Elixir’s version of it and it is easy enough to depend on a git url in any case. ^.^

It was likely simply not considered to add .core support since it’s an undocumented format that can change in backwards incompatible ways at any time. This is the first time someone asked for it (afaik) in the 4+ years mix has existed so maybe it’s a good thing features are not added until the feature is needed :).

A PR to elixir that added .core support would probably be approved.

Nah don’t worry about it, already spoken with Jose, it is too esoteric to be added (for good reasons) and it was not hard to hack it in anyway (I should make a version that just handles core files instead of multiple erlang formats). I am just using a pre-processor that takes erl files, compiles them to core, modifies the core (because scoping rules and parsing is a bit easier for what it is modifying) and spits back out the altered core files for erlang to compile as normal. :slight_smile: