Skip to content
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

[dotnet] update to .netcore v1.0.1; add osx build #1810

Merged
merged 1 commit into from
Apr 17, 2017

Conversation

xied75
Copy link
Contributor

@xied75 xied75 commented Apr 4, 2017

This updates dotnet build to use .netcore v1.0.1. And we added an osx build for dotnet.

But:

1, the osx runs more than 47 mins, and always got terminated by Travis, but it definitely works.
2, there is an issue preventing linux dotnet target working at all, there is nothing we can do other than hope Microsoft fix it asap. https://github.com/dotnet/core-setup/issues/1947

@ericvergnaud @parrt

@parrt
Copy link
Member

parrt commented Apr 4, 2017

Interesting that it takes so long on os x. I will let @ericvergnaud try it out and let me know how it goes. I can try it also

@xied75
Copy link
Contributor Author

xied75 commented Apr 11, 2017

ping ?

@ericvergnaud
Copy link
Contributor

ericvergnaud commented Apr 11, 2017 via email


try {
// add Runtime project reference
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Adding a reference to the project (runtimeProjPath) rather than the Assembly is likely to be the cause of the very long Travis build with both Linux and MacOSX. I'm guessing this tells dotnet to rebuild both the test project and the runtime project.
Have you tried simply referencing the Assembly here?

@ericvergnaud
Copy link
Contributor

Hi,

it seems that the Ubuntu issue is solved, see https://travis-ci.org/antlr/antlr4/builds/218514385. Great!
Indeed the MacOSX build fails due to Travis timeout.

Re build time, I looked into it, see my comments in BaseCSharpTest.java/buildDotNetProject.

I was also able to build on MacOSX, and currently updating 'releasing-antlr.md' accordingly.

Re Nuget I noticed that the target assembly has not been renamed i.e. it has the same name as the Standard one. Can you change this to be 'Antlr4.Runtime.Core.dll' ? Then I can publish to Nuget.

Good job!

@parrt
Copy link
Member

parrt commented Apr 16, 2017

@ericvergnaud looks like it still times out on Mac. should I wait to merge?

@ericvergnaud
Copy link
Contributor

ericvergnaud commented Apr 17, 2017 via email

@parrt parrt added this to the 4.7.1 milestone Apr 17, 2017
@parrt parrt merged commit efc0a14 into antlr:master Apr 17, 2017
@xied75
Copy link
Contributor Author

xied75 commented Apr 18, 2017

Regarding test run, just curious, the C++ test on OSX is also timing out, what is the reason there? Are they not going to improve on this?

@parrt
Copy link
Member

parrt commented Apr 18, 2017

unfortunately that is probably a limitation of C++ :(

@xied75
Copy link
Contributor Author

xied75 commented Apr 25, 2017

@ericvergnaud The PR you just commented on is the old one, so I'll reply here instead.

Sorry for the radio silent. I'm busy trying to get a StringTemplate4 working on Antlr4 runtime in C# now, I need that for my product urgently.

Regarding the timeout, I don't think the runtime was compiled for each test. I need to investigate further, being this slow is embarrassing when other languages able to finish in 4 or 5 minutes. But I did notice cpp on Mac is also timing out.

Regarding the naming of the dll, my opinion is that calling it Antlr4.Runtime.Core is confusing, as Core normally means the bare central pieces of functions for a library, e.g. https://www.nuget.org/packages/Castle.Core/
But we are trying to use it to mean dotnet core. So a clearer name could be:
Antlr4.Runtime.netcore or Antlr4.Runtime.netstandard, let me know what you think.

@ericvergnaud
Copy link
Contributor

ericvergnaud commented Apr 25, 2017 via email

@xied75 xied75 deleted the dotnetcore branch April 25, 2017 22:31
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants