Skip to content

Conversation

alco
Copy link
Member

@alco alco commented Aug 16, 2014

Closes #2656 and #2657.

@alco
Copy link
Member Author

alco commented Aug 17, 2014

Hm, some Logger tests failed. I didn't have those failures locally.

Anyway, please hold on with merging. I want to amend the escript test to use config.exs.

@alco
Copy link
Member Author

alco commented Aug 17, 2014

All done.

@ericmj
Copy link
Member

ericmj commented Aug 18, 2014

The :language project config here needs to be documented on escript.build and probably also on compile.app.

@alco
Copy link
Member Author

alco commented Aug 18, 2014

@ericmj done

@ericmj
Copy link
Member

ericmj commented Aug 18, 2014

Great. LGTM.

@josevalim josevalim added this to the v1.0 milestone Aug 18, 2014
[{'#{name}.beam', binary}]
end

defp module_body_for(:elixir) do
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We don't need to have two bodies. Let's just have one with everything written in Erlang.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What to do with Application.format_error? If it wasn't for it, then it is easy to have all common functions except for the main one.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We can do: case :code.ensure_loaded(Application) do {:module, Application} -> call_it; {:error, _} -> dont_call_it end

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I just realized we do need two bodies... but we can probably share some code between them?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Like load_config and maybe io_error unsure.

@josevalim
Copy link
Member

I have added some comments. Do we want to support --erlang on mix new?

@alco
Copy link
Member Author

alco commented Aug 20, 2014

Do we want to support --erlang on mix new?

Not in this PR. I wanted to play with a generic templating solution for mix new.

@alco
Copy link
Member Author

alco commented Aug 20, 2014

@josevalim what do you think about the last commit? Only the main function differs between Elixir and Erlang. Whether to color the error output is decided at build time.

And there is also a bug, I realized now: need to replace :red and co with ANSI escapes.

@alco
Copy link
Member Author

alco commented Aug 20, 2014

The tests didn't catch that. Maybe we should remove coloring altogether? It's not extremely important here.

@alco
Copy link
Member Author

alco commented Aug 20, 2014

@josevalim fixed error formatting issues in the latest commit (I can squash it before merging). This is not tested as part of our test suite, I tried it manually with an Erlang project that fails to start.

@josevalim
Copy link
Member

@josevalim what do you think about the last commit?

It has a beautiful sha.


if unquote(colors_enabled) do
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Let's just drop the color altogether because escripts will probably never have the colors enabled because they are not started through the bin/elixir executable.

@alco alco force-pushed the mix-language-setting branch from c1d614f to f0b8bc1 Compare August 20, 2014 17:39
@alco
Copy link
Member Author

alco commented Aug 20, 2014

Rebased, ready to merge.

@josevalim
Copy link
Member

Beautiful. Merge it!

alco added a commit that referenced this pull request Aug 20, 2014
@alco alco merged commit 74391b7 into elixir-lang:master Aug 20, 2014
@alco alco deleted the mix-language-setting branch August 20, 2014 17:56
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging this pull request may close these issues.

Escripts generated by 'mix escript.build' rely on Elixir
3 participants