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. |
Beta Was this translation helpful? Give feedback.
-
I tested
The exit code is 0 regardless of the last line, since we have some expected test failures. I don't think the |
Beta Was this translation helpful? Give feedback.
-
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. |
Beta Was this translation helpful? Give feedback.
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 test
enough? Because in my system, excludingtest
, all the other test rule in Makefile fails (test262
,test262-check
,test262-fast
andtest262-update
).Also relevant to the earlier point - is it okay if I do not pull submodules (
test262
) when trying to build?Beta Was this translation helpful? Give feedback.
All reactions