Skip to content
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

Escriptize based on configured apps only #1249

Merged
merged 2 commits into from
Jul 9, 2016

Conversation

ferd
Copy link
Collaborator

@ferd ferd commented Jun 27, 2016

Prior to this patch, the escriptize command flat out selected all
declared dependencies.

This patch instead looks at the app files and only includes the
dependencies of the top level app and the extra ones, avoiding to
package more apps than required.

This required a version bump on cth_readable as it mistakenly included
'syntax_lib' instead of 'syntax_tools' as a dependency.

Attempt at fixing #1139

Prior to this patch, the escriptize command flat out selected all
declared dependencies.

This patch instead looks at the app files and only includes the
dependencies of the top level app and the extra ones, avoiding to
package more apps than required.

This required a version bump on cth_readable as it mistakenly included
'syntax_lib' instead of 'syntax_tools' as a dependency.
Used a nonexisting option instead of a correct one
@ferd ferd changed the title WIP: Escriptize based on configured apps only Escriptize based on configured apps only Jun 27, 2016
@tsloughter
Copy link
Collaborator

So apps in .app.src if not system libs and those in incl_apps, looks good to me. +1

@ferd ferd merged commit 8f6c13d into erlang:master Jul 9, 2016
ferd added a commit to ferd/rebar3 that referenced this pull request Aug 10, 2016
erlang#1249 introduced a mechanism by
which escript dependencies of applications only would be included; this
required adding a filter to skip system libraries in the OTP root
because that tends to break escripts in very nasty ways.

However, the problem came that some libraries are just not in the
escript path but may still be included; for these libraries the path
prefix check failed as they return `{error, bad_name}` from
`code:lib_dir(Dep)` rather than just the path they're in --
specifically, this happens with top level apps.

The issue was reported in erlang#1294
and the current patch fixes it by accepting a `bad_name` dep as valid,
since it is obviously not in the root path.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants