With this in place, I would expect the code from the Makefile that does the generation is no longer needed. And with it some other changes can be removed too.

lib/Gherkin/Generated/Languages.pm:
	perl helper-scripts/build_languages.pl > $@

Currently the Makefile targets are still used for the GitHub Actions CI runs. Those runs are specialized because they depend on the conformance data, which isn't packaged in the release tarball. I need to check again, but from what I remember dzil passes a cleaned environment to the test scripts, so the scripts needed a predictable directory to find the conformance data.

The dzil build target only packages the files for release. The dzil test target only runs a few syntax checks. Definitely not enough to validate conformance.

Yes, the Makefile as a whole is still used.

But you've created an alternative for the generation of lib/Gherkin/Generated/Languages.pm. And I would generally expect a build process to have a single way of doing this. So I would not expect perl helper-scripts/build_languages.pl to be invoked in the Makefile anymore.

Perhaps dzil build would have to be invoked instead cpanm? And perhaps the acceptance tests would have to be ran with the artifact produced by dzil build?

perl5:
	cpanm --notest --local-lib ./perl5 --installdeps --with-develop .

Running the tests with an environment as it would have been created by installing the artifact from dzil build , can be done using dzil test (to run the Perl test suite) or dzil run (to run an arbitrary command).

I guess what it comes down to is: should the Makefile follow the patterns all other Makefiles use (thereby deviating from "the Perl way")? Or should I use "the Perl way", thereby deviating from "the project way"?

I guess I know the answer: since Elixir doesn't do it the project way anyway, so there's precedent for doing it "the language's ecosystem way". I'll change this PR to de-duplicate accordingly.

I'm not sure I know what the "Perl way" is. ;)

But most languages do follow the pattern of executing the code in the artifact produced by the build system - occasionally with a shim.

For example JavaScript uses npm to build the artifact.

.built: node_modules dist $(SOURCE_FILES)
	touch $@

node_modules:
	npm install

dist:
	npm run build

And then to run the tests

GHERKIN = node ./test-cli.mjs

Where test-cli.mjs is a shim that uses Gherkin to run the acceptance tests.

Perl seems to differ mostly in that it uses both cpanm (to create the artifact used by tests) and dzil (to create the released artifact). I would prefer it if we have system for both.

Perl seems to differ mostly in that it uses both cpanm (to create the artifact used by tests)

Ah! There'sa misconception there. Good to be able to clarify that. cpanm is actually not building the artifact (dzil build is); cpanm is about installing the dependencies to be able to run the tests (as well as dzil itself). Until this PR (which removes lib/Gherkin/Generated/Languages.pm) the tests can be run without any build steps straight out of the repository.

This PR changes that, because with this PR a build step is required (generating the missing languages file) before the tests can be run. This is an extra step being introduced in this PR.

My plan now is to change the acceptance Makefile target: it will invoke dzil test, which will generate the missing languages file. I will also change the acceptance/* targets to Perl code which can be run as part of dzil test (which assumes it can run the files in t/ as Perl test files; it doesn't invoke the project's Makefile).

I will also change the acceptance/* targets to Perl code which can be run as part of dzil test

This part has me a little confused. The way the acceptance tests are run seems correct to me.

Until this PR (which removes lib/Gherkin/Generated/Languages.pm) the tests can be run without any build steps straight out of the repository.

Then I would now expect perl helper-scripts/build_languages.pl to be replaced with dzil build or something like that.

This part has me a little confused. The way the acceptance tests are run seems correct to me.

They are as long as the file lib/Gherkin/Generated/Languages.pm exists, but this commit removes that file. Instead, I'm invoking dzil build, which generates a release tarball, but Perl can't use that tarball to load its modules from. It also generates a directory with the content of that tarball, but that has the version number embedded (making the Makefile a more complex).

To keep the makefile simple, I was going to go with the way Elixir works, but that breaks down for other reasons (the URI value).

I've taken yet another direction with this PR now, based on your comments and my findings so far.