-
Notifications
You must be signed in to change notification settings - Fork 31
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
rebar3 woes #47
Comments
Can you provide a minimum reproducible code? It is unlikely I will be able
to do anything if the problem is incompatibility between versions, but if
this is just an erlang compilation issue (maybe missing some flags) I can
try to fix it
…On Mon, May 29, 2023 at 10:41 AM ericb-summit ***@***.***> wrote:
I realize this is not directly evm problem, but just asking if there's
some way to kill 2 birds with one stone here.
It looks like something changed in > erl23 and a rebar3 compiled with
sayl, er23 barfs when run against erl25 with
init terminating in do_boot ({undef,[{rebar3,main,[],[]},{init,start_em,1,[]},{init,do_boot,3,[]}]})
This requires recompiling rebar3 when switching with evm. What would be
the cleanest way to leverage how evm works such that switching evm would
also switch rebar3 version? I can do the work and send a PR. Thanks.
—
Reply to this email directly, view it on GitHub
<#47>, or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAA66LLOW6NH4BVXCUJZKWTXISRRRANCNFSM6AAAAAAYS2COZQ>
.
You are receiving this because you are subscribed to this thread.Message
ID: ***@***.***>
--
Robison W R Santos
|
Sorry let me be sure I explained properly: Let's say I Now if I, say But then going back to So my question was, in a way: is there some place I could put the version-specific rebar3 so a specific rebar3 would follow |
In theory yes, but I don't know exactly how rebar and the Erlang compiler
get "linked" after the rebar installation. We would need to understand how
Erlang finds the installed binaries to use and select the "right" versions
depending on the selected version of Erlang.
…On Mon, May 29, 2023, 11:30 PM ericb-summit ***@***.***> wrote:
Sorry let me be sure I explained properly:
Let's say I evm use 23.3.4.18, and install rebar3 from sources, which is
just ./bootstrap && ./rebar3 local install which pops it into
~/.cache/rebar3/bin/rebar3. Of course rebar3 works fine at this point.
Now if I, say evm use 25.3.2, rebar3 won't work, due to some
incompatibility between the compiled rebar3 and erl/otp 25.3.2. So, I
have to rebuild it, git clean -dffx && ./bootstrap && ./rebar3 local
install and this newly compiled rebar3 will work on 25.3.2.
But then going back to evm use 23.3.4.18 I would have to recompile rebar3
again.
So my question was, in a way: is there some place I could put the
version-specific rebar3 so a specific rebar3 would follow evm use xxx ?
Would it be okay if we simply placed rebar3 for example in
~/.evm/erlang_versions/otp_src_25.3.2/bin/erl for 25.3.2 and similarly
for other versions?
—
Reply to this email directly, view it on GitHub
<#47 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAA66LJCAQT6NMV6OY3FTHDXIVLVFANCNFSM6AAAAAAYS2COZQ>
.
You are receiving this because you commented.Message ID:
***@***.***>
|
This is what installed rebar3 looks like
Within that .cache/rebar3/.. folder are beam files kind of like an installed erlang release. That complicates things a bit. I think I might reach out to ferd to get his input on this. |
If we can make rebar install in different folders and then, somehow,
manipulate the path whenever we use a different version of Erlang, then
that problem would go away. For that we would need to either manage rebar
installation via evm or install rebar where we want it to be manually. We
would need to teach evm to load rebar anyways, so probably the first option
is better.
Problem is, I don't think I have the bandwidth to do this in the time you
might need it.
…On Tue, May 30, 2023, 8:59 AM ericb-summit ***@***.***> wrote:
This is what installed rebar3 looks like
#!/usr/bin/env sh
## Rebar3 3.22.0+build.5277.ref44d0587a
REBAR3_VSN=${REBAR3_VSN:-3.22.0+build.5277.ref44d0587a}
erl -pz /home/enry/.cache/rebar3/vsns/${REBAR3_VSN}/lib/*/ebin +sbtu +A1 -noshell -boot start_clean -s rebar3 main $REBAR3_ERL_ARGS -extra "$@"
Within that .cache/rebar3/.. folder are beam files kind of like an
installed erlang release. That complicates things a bit. I think I might
reach out to ferd to get his input on this.
—
Reply to this email directly, view it on GitHub
<#47 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAA66LIOYL4W7XMG6MRJHT3XIXOINANCNFSM6AAAAAAYS2COZQ>
.
You are receiving this because you commented.Message ID:
***@***.***>
|
Ok so turns out rebar3 is by design friendly to current +2 versions of erlang. So:
I can live with with current + 2 version it's a fair limitation. We can close this. |
I realize this is not directly evm problem, but just asking if there's some way to kill 2 birds with one stone here.
It looks like something changed in > erl23 and a rebar3 compiled with sayl, er23 barfs when run against erl25 with
This requires recompiling rebar3 when switching with evm. What would be the cleanest way to leverage how evm works such that switching evm would also switch rebar3 version? I can do the work and send a PR. Thanks.
The text was updated successfully, but these errors were encountered: