Add partial support for Erlang/OTP 17

[norton]

Allow rebar to compile applications using Erlang/OTP 17 and older
versions. This patch only provides partial support since the rebar
tool itself must be compiled using an Erlang/OTP version that is older
than 17.

[Vagabond]

Can you add a couple unit tests? This looks fine otherwise.

[norton]

Done. Coincidentally, the automatic define of 'TEST' for eunit isn't working (for me).

$ make clean
$ make
$ make test

[Vagabond]

I think when rebar eunit runs, the modules that comprise rebar are loaded from the rebar escript, not from the .eunit directory, so while the modules in .eunit are compiled with TEST, those aren't the ones that are run.

It might be better to export the function you're testing and add a test module to test/ so this will work right.

[ghost]

@norton if you decide to export the functions, make sure you add them here to note that it's for internal use only. With that said, can't we test this by invoking a rebar command like we do in the existing tests? Alternatively you could try to prepend ~/.eunit to the code path, but 1) that may not work and 2) could be considered a kludge.

[norton]

Give me a clear request on what/how you would like this unit test to be done. I do not (yet) know much about the existing tests that are run by invoking a rebar command. I expected (but my expectation was wrong) that rebar would simply run the eunit tests in the given module without having to export the function.

[ghost]

1. @Vagabond's suggestion to export the function and move the test to a file in test/ is the easiest solution, but we might not want to export the function. Still, if you add it to the "for internal use only" export directive, it's okay.
2. As you discovered, due to the way escript archives are loaded and added to the code path, rebar eunit does not pick up .eunit/rebar_require_vsn.beam. You could try to prepend .eunit to the code path after rebar has started and eunit is about to be run (to see if rebar eunit does what you initially expected).
3. Invoking rebar and testing the output or behavior for correctness may not cover all test cases or be as easy to achieve, so it's just something to consider.

Going with option 1. is fine, 2. is worth a try, and 3. is less likely to work.

If you have time, give 2. a try, otherwise follow @Vagabond's suggestion.

Sorry, if I wasn't clear on this.

[norton]

Option 1 has been committed and pushed.

[ghost]

@norton thanks.