Decompose XS-APItest#24523
Open
demerphq wants to merge 36 commits into
Open
Conversation
We have handy00.t through handy09.t, each of which wants to process 1/10th of the total handy tests, but by some oversight we ended up with a situation where if TEST_JOBS was not set we would actually execute all of the handy tests in just handy00.t, and the do no testing at all in handy01.t through handy09.t, which is sort of weird. I also don't really understand why we would split the test set differently dependening on the number of TEST_JOBS. I can see that causing confusion. I think its much better if the only time we dont use the normal 10 chunk partition is when someone wants to run handy00.t and have it test everything, which this patch achieves by trigger the special behavior with a new explicit env var instead of indirectly via TEST_JOBS==1 (implied or explicit) or other tricks. So with this patch unless you explicitly set FULL_HANDY_TEST to true then handy00.t and friends will test exactly the same tests for everyone everywhere. If FULL_HANDY_TEST is true then any of the handy test files will run all the tests. So don't set that unless you know what you are doing. Personally I think this makes more sense overall anyway, if something in handyNN.t breaks it would be nice to not have to run the full handy test suite (~170k tests) to find one mistake, much better to only have to run 17k tests instead.
Leont
added
the
defer-next-dev
Contributor
|
On Thu, Jul 02, 2026 at 09:51:33AM -0700, Yves Orton wrote:
APItest.xs was insanely long, like 200k lines of code or something.
Only 8K lines; 200k bytes.
But yeah, I approve of the general idea of splitting APItest.xs into
per-package files.
|
Contributor
|
The failing tests are just upset about I think this is a great idea to split them up. I know there's several other PRs hanging around with "defer-next-dev" tagged on them, that this will cause to conflict. But since all of those (several of which are mine) are just making additions, I think it best to merge this one first, and then go and fix up the other ones and move those additions to the same scheme as this. I'm happy to take the lead on that. (I did email perl5-porters@ with a big grand plan, but the mailing list seems not to be working currently. I have copypasted the message here - https://paste.debian.net/hidden/1b8b7ba1) |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
4 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
APItest.xs was insanely long, like 8000 loc / 200k worth of code or something (/update: corrected this, thanks @iabyn/). This patch sequence splits it out into multiple logical blocks by using the XS INCLUDE directory, and C include statements.
This also includes some tweaks to how ext/XS-APItest/t/handyNN.t worked so that jobs parallelize out more consistently and more reasonably.
The idea is that adding next tests to XS-APItest is pretty intimidating, splitting it up hopefully makes it a little easier.
No tests should be broken or removed by this patch. It is purely about reorganizing one of our largest compilation units.