-
-
Notifications
You must be signed in to change notification settings - Fork 690
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
Upgrade to berp 1.3, remove dependency to mono #1542
Conversation
Is this good to merge now? LGTM! |
@aslakhellesoy no, this is now only fixes it for dotnet. But a review is welcome. If you are fine with the approach, i will replicate it to the other languages. |
@aslakhellesoy what do you think about creating a shared.mk file that is a single file in the templates, but it is rsynced to all language folders. That way we could reduce the duplications in the language specific default.mk files... |
We could, but it might come at the cost of additional complexity. Have a go at it if you want! |
* origin/master: (50 commits) Update dependency @babel/core to v7.14.3 Use v0.4.4 of build container Update typescript-eslint monorepo to v4.24.0 Post release json-to-messages v8.0.0 Release json-to-messages v8.0.0 Release fake-cucumber v12.0.1 Release gherkin-utils v5.0.2 Release gherkin-streams v2.0.2 Release message-streams v2.0.0 Release html-formatter v14.0.0 Release react v14.0.0 Release compatibility-kit v5.0.0 Post release json-formatter v18.0.0 Release json-formatter v18.0.0 Release query v10.0.0 Release fake-cucumber v12.0.0 Post release create-meta v5.0.0 Release create-meta v5.0.0 Release gherkin-utils v5.0.1 Release gherkin-streams v2.0.1 ... # Conflicts: # gherkin/dotnet/.gitignore # gherkin/dotnet/Gherkin/Gherkin.csproj # gherkin/dotnet/Makefile # gherkin/dotnet/default.mk
@aslakhellesoy @mattwynne how can it be that gherkin-java does not understand "dotnet" is that running on a different docker container? |
@gasparnagy yes: Lines 609 to 610 in fff7cc2
Also see my comment here: #1534 (comment) |
@aslakhellesoy I see. So probably this was working so far, because the parser was never outdated and therefore berp wasn't invoked. But since I introduced the Is there an easy way in make to say that it should only invoke the target if the other targets are outdated? |
Yes, by using Make the way it was meant to be used :-) Make targets should be files, not abstract names. Here is an example: foo:
echo "hello" Running foo:
echo "hello" > $@ (The Let's get more advanced. The foo: bar
echo "hello" > $@
car bar > $@ Create the Now, if you I hope that helps. I can have a look at this tomorrow if you haven't figured it out. |
@aslakhellesoy Thx. At that level I was OK, but here I need to make sure that berp is installed... that is not a classic target, because it is only needed for another target to be established. The "make" way would be (base on my understanding):
This is more or less what I have now, but this will attempt to install berp even if the parser is up-to-date (on eg. the java parallel build, where it is not possible). I tried now with some tricky Or I just give up using .NET restore for berp and upload it as a linux binary somewhere... But I thought it is easier to maintain the versions this way... |
@aslakhellesoy I think I have found a solution using a canned recipe for berp. https://github.com/cucumber/common/pull/1542/files#diff-b20a2c0f8de33a0b6b48411e3a44c33a583536f315050f81229be990eb42657eR70-R73 And the usage is simple now: |
@aslakhellesoy for some of the languages, the parser generation fails with the new berp version and so I need to fix those still:
(It only passes now because the parsers are not outdated.) |
🥳 |
Upgrading Berp to a version runs on .NET 5.0