Repository navigation
Replies: 3 comments 17 replies
|
If you want to be thorough, the test262 suite should be run. There is a fast variant, but even the "slow" one is fast enough now, thanks to the multi-threading enhancements Ben made. |
11 replies
|
I tested The exit code is 0 regardless of the last line, since we have some expected test failures. I don't think the |
4 replies
|
I noticed you guys don't provide the test262.patch. The original fork shows that test262.patch was updated 2 weeks ago, but non262.js on the test262 site was updated last week. |
2 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
I am trying to package the next-gen version of QuickJS in Guix - which may replace the older, unmaintained version or exist as it's own new package - that, I'll have to ask the Guix maintainers.
Usually the packages build out of the box without any issues just by setting the build system (in this case,
cmake-build-system), but given how CTest wasn't used (hope that I am not wrong here), I wish to understand - as a package maintainer, what relevant tests should I run to ensure that the package expression ensures reproducible builds?Is
make testenough? Because in my system, excludingtest, all the other test rule in Makefile fails (test262,test262-check,test262-fastandtest262-update).Also relevant to the earlier point - is it okay if I do not pull submodules (
test262) when trying to build?All reactions