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

Non-relocatable binary causing issues on Heroku #2079

Closed
jmorrell opened this Issue Sep 29, 2017 · 7 comments

Comments

Projects
None yet
2 participants
@jmorrell

jmorrell commented Sep 29, 2017

The built compiler is not relocatable out of box, please don’t move it around unless you know what you are doing

Background: users push their apps to Heroku, and we install their Node dependencies for them and run their build script. To speed up subsequent builds we cache node_modules by default.

Additionally the application is build in a temporary directory on our build servers that changes with each deploy. This is something we'd like to change so that all builds happen in the same directory, but this is not likely to happen until next year.

This causes issues with users trying to use bucklescript through something like bs-loader for webpack. They can fix the issue by disabling the cache, but this means much longer build times.

I'd love to see more people using bucklescript on Heroku. Can you help me understand at a high level why it's not relocatable? Do you have any suggestions for how I might be able to help these users?

@jmorrell

This comment has been minimized.

Show comment
Hide comment
@jmorrell

jmorrell Sep 29, 2017

If making the binary relocatable is too complicated, would you be open to a PR that detects when the binary has been moved and prints an error message with an explanation? The current error message is not very helpful in understanding what has gone wrong:

remote:        Error: Unbound module Pervasives

jmorrell commented Sep 29, 2017

If making the binary relocatable is too complicated, would you be open to a PR that detects when the binary has been moved and prints an error message with an explanation? The current error message is not very helpful in understanding what has gone wrong:

remote:        Error: Unbound module Pervasives
@bobzhang

This comment has been minimized.

Show comment
Hide comment
@bobzhang

bobzhang Sep 30, 2017

Member

Error: Unbound module Pervasives means the compiler could not find it stdlib library,
we want to make our compiler relocatable: relevant #2038

Member

bobzhang commented Sep 30, 2017

Error: Unbound module Pervasives means the compiler could not find it stdlib library,
we want to make our compiler relocatable: relevant #2038

@bobzhang

This comment has been minimized.

Show comment
Hide comment
Member

bobzhang commented Oct 20, 2017

@jmorrell

This comment has been minimized.

Show comment
Hide comment
@jmorrell

jmorrell Oct 20, 2017

Nope nope. How does that help?

The solution I proposed to the user who had issues was to not cache node_modules. This means that each time they push their app, bucklescript gets installed from scratch by npm, which dramatically slows down builds.

It's also broken and confusing by default. A better error message would go a long way here.

jmorrell commented Oct 20, 2017

Nope nope. How does that help?

The solution I proposed to the user who had issues was to not cache node_modules. This means that each time they push their app, bucklescript gets installed from scratch by npm, which dramatically slows down builds.

It's also broken and confusing by default. A better error message would go a long way here.

@bobzhang

This comment has been minimized.

Show comment
Hide comment
@bobzhang

bobzhang Nov 1, 2017

Member

relevant: ocaml/ocaml#795
Think of using a relative path to locate standard library path based on Sys.executable_name

  • more robust Sys.executable_name
  • not relying on Filename.dirname since it may not work with symlink
    previously the layout is
|- bin - bsc.exe
\- lib  - ocaml - *.cmi

lets lift it into

|- bsc.exe
\- lib - ocaml - *.cmi
Member

bobzhang commented Nov 1, 2017

relevant: ocaml/ocaml#795
Think of using a relative path to locate standard library path based on Sys.executable_name

  • more robust Sys.executable_name
  • not relying on Filename.dirname since it may not work with symlink
    previously the layout is
|- bin - bsc.exe
\- lib  - ocaml - *.cmi

lets lift it into

|- bsc.exe
\- lib - ocaml - *.cmi
@bobzhang

This comment has been minimized.

Show comment
Hide comment
@bobzhang

bobzhang Nov 4, 2017

Member

@jmorrell it should be done in master, let me know if you have further issues with regard to caching

Member

bobzhang commented Nov 4, 2017

@jmorrell it should be done in master, let me know if you have further issues with regard to caching

@bobzhang bobzhang closed this Nov 4, 2017

@jmorrell

This comment has been minimized.

Show comment
Hide comment
@jmorrell

jmorrell commented Nov 6, 2017

Thanks @bobzhang!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment