-
-
Notifications
You must be signed in to change notification settings - Fork 66
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
perl: Languages.pm is not mergable #32
Comments
@ehuelsmann could you have a look at this too? |
Hmm. I actually chose this structure for 2 reasons: to make it as small as possible and, because it's generated, it's not the authoritative source. The other solution is to generate this file during CI and release runs instead of keeping it in the repo as a versioned resource (this is the strategy I use in other projects). Do we really have to generate these files as part of the language update? People seem to regularly submit language updates without regenerating the language files in all implementations anyway. That would kill 2 birds with one stone. |
Unfortunately it depends. For example for Go, yes we have to because it's consumed directly from Git rather than through a package manager. But on the other hand for Java this isn't nessesary, each time the project is build a file is generated using a build step in Maven. If Perl has hooks to execute Perl code in the build step (I think it's |
I haven't tried this, but this does look promising |
Yes. We could run the "build languages" script just before running anything in the Makefile and include the file in our distribution build procedure. |
That's not quite the right solution. Because then if you were to build the project without the make file, it wouldn't work. Using |
Hmm. How does Java deal with the need to have the file around in order to
run the test suite? For Perl, I can (and need to) run the test suite
straight out of the repository: only the most basic tests are being run
after the "build" step, because otherwise the full test data would need to
be included in the distribution archive. Which is rather useless, given
that they are development time tests.
|
Maven (for Java) has a generate sources phases that executes before compiling code and running tests. We generate the classes from the languages.json in this phase. |
🤔 What's the problem you've observed?
Currently the generated
Languages.pm
consists of a single line.gherkin/perl/lib/Gherkin/Generated/Languages.pm
Lines 1 to 7 in 1cc2ef0
As a result, when multiple contributors submit changes to
gherkin-languages.json
their PR's will always conflict. Because PRs are not often looked at this happens more often then you'd think.✨ Do you have a proposal for making it better?
Consider changing
build_languages.pl
so it generates the file with some formatting.The text was updated successfully, but these errors were encountered: