Closed un-def closed 9 months ago
Attention: 1 lines
in your changes are missing coverage. Please review.
Comparison is base (
7f74fc8
) 79.78% compared to head (7151f5e
) 68.71%.
Files | Patch % | Lines |
---|---|---|
hererocks.py | 80.00% | 1 Missing :warning: |
:exclamation: Your organization needs to install the Codecov GitHub app to enable full functionality.
:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.
@hishamhm Hi, you review is not mandatory, just trying to keep up to date. I am by no means an expert in C/build tools/enviroments, I am mostly a web developer, so an extra pair of eyes would be great!
@un-def yes, the change itself and the description of your experiment in the PR description LGTM!
LuaJIT recently switched to the rolling release scheme:
See LuaJIT commits:
Fixes: https://github.com/luarocks/hererocks/issues/25
In addition to the changing of the versioning scheme, there has been introduced some changes in the MinGW build.
See the commit and the PR:
The problem is that if
sh
is inPATH
, mingw32-make will usesh
instead ofcmd.exe
, but some recipes in Makefile usecmd.exe
syntax if MinGW is detected. I have no solid proof of it, only this post on Stack Overflow, but I did a simple experiment:I have a machine with Windows and
sh.exe
/bash.exe
provided by Git for Windows.I've tried to install LuaJIT@v2.1 from the official repository (not using hererocks, only official instructions) with no success:
As you can see, bash tries to execute Windows batch script and fails (
syntax error near unexpected token
)The same with
clean
recipe:Yep,
del
instead ofrm
.But when I either removed
sh.exe
fromPATH
or run mingw32-make withSHELL=cmd
, all problem disappeared.With this patch, we force mingw32-make to use Windows shell (
SHELL=cmd
).