jose_server.erl - syntax error before: 'catch', function handle_call/3 undefined

[licaon-kter]

Environment

• Erlang version: Erlang (SMP,ASYNC_THREADS) (BEAM) emulator version 11.1.8 (from source)
• OS: Debian Bullseye arm64
• rebar built at erlang/rebar3@b64d94f (from source)

Trying to build HEAD (13ebe89)

...
===> Compiling yconf
===> Compiling jose
===> Compiling _build/default/lib/jose/src/jose_server.erl failed
_build/default/lib/jose/src/jose_server.erl:137: syntax error before: 'catch'

_build/default/lib/jose/src/jose_server.erl:32: function handle_call/3 undefined

make: *** [Makefile:215: _build/default/lib/.built] Error 1

Last good build that I had was dbf0fb8

git bisect says:

da8c9f33572eb6c6ccff8f9fe71cd7b629bae575 is the first bad commit
commit da8c9f33572eb6c6ccff8f9fe71cd7b629bae575
Author: Badlop <badlop@process-one.net>
Date:   Tue Apr 23 13:45:14 2024 +0200

    rebar.lock: Track it, now that rebar3 uses loose dependency versioning
    
    This is recommended in Rebar3 documentation:
      [Lock files] should always be checked into source control.
      https://rebar3.org/docs/configuration/dependencies/#lock-files

 .gitignore |  1 -
 rebar.lock | 87 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
 2 files changed, 87 insertions(+), 1 deletion(-)
 create mode 100644 rebar.lock

[licaon-kter]

Looks like those commits helped, HEAD (392d7ee) builds fine now.

[badlop]

The problem explained in this issue is a follow up of the previous one, both related to rebar.lock tracking:

• Rebar3 downloads all dependencies in rebar.lock, even the disabled ones #4212 involves dependencies that are disabled using ./configure
• jose_server.erl - syntax error before: 'catch', function handle_call/3 undefined #4213 involves dependencies that use different version depending on the Erlang/OTP version.

Erlang version: Erlang (SMP,ASYNC_THREADS) (BEAM) emulator version 11.1.8 (from source)

Ok, that is Erlang/OTP 23.2.

For erlang above 23, rebar.config says to use jose 1.11.10, which uses the new try catch Class:Reason:Stacktrace. And the rebar.lock file tracked in git mentions a commit in that version.

Otherwise (erlang not above 23), rebar.config says to use 1.11.1, which does not use the new try catch Class:Reason:Stacktrace. However, the rebar.lock file tracked in git does not mention a commit in that version.

This is fixed in f7dc4fa

BTW, this problem was not detected by the CI or Runtime workflows because they explicitly called "make update", which gets the dependencies as stated in rebar.config. This is fixed in 025e2a5

[licaon-kter]

Erlang version: Erlang (SMP,ASYNC_THREADS) (BEAM) emulator version 11.1.8 (from source)

Ok, that is Erlang/OTP 23.2.

Oh wait, I did a mistake :(

That's the system installed one, and erl is in path hence its output was pasted.

I actually built a newer one and forgot to use its erl which would say: Erlang (SMP,ASYNC_THREADS) (BEAM) emulator version 14.1.1

BTW, this problem was not detected by the CI or Runtime workflows because they explicitly called "make update", which gets the dependencies as stated in rebar.config.

But on a fresh clone I can't run make update, right?

Fresh clone I do: autogen/configure/make

If I update the local clone, then I do: git pull/autogen/make update/configure/make

This was learned from experience, aka updating a tree without doing make update would yield strange results.

[badlop]

I actually built a newer one ... emulator version 14.1.1

erts 14.1.1 was included in https://www.erlang.org/patches/otp-26.1.2

If you are using OTP 26, then the version of Jose that rebar3 downloads is not affected (or should not be affected) by commit f7dc4fa ...

But on a fresh clone I can't run make update, right?
Fresh clone I do: autogen/configure/make

Well, it can be used anytime, either on clean build or when rebuilding. Of course, it makes little sense to run in on a clean build.

To test the build process, CI and Runtime test workflows should not use it (fixed in 025e2a5 ), that way they test the typical (and documented) build steps: ./autogen.sh && ./configure && make && make install/prod/whatever

If I update the local clone, then I do: git pull/autogen/make update/configure/make
This was learned from experience, aka updating a tree without doing make update would yield strange results.

Right, make update is useful when rebuilding after rebar config files have changed (git pull or whatever), to get the dependencies versions that may now be required.