-
Notifications
You must be signed in to change notification settings - Fork 3.3k
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
Conversation
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 |
ping ? |
Hi, sorry haven’t had much time to look into this yet. It’s on my todo list.
… Le 11 avr. 2017 à 21:06, Dong Xie ***@***.***> a écrit :
ping ?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub <#1810 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ADLYJIQblbE0A-fxtGYZgk3oFUMovTe7ks5ru3rUgaJpZM4MzDTn>.
|
|
||
try { | ||
// add Runtime project reference |
There was a problem hiding this comment.
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?
Hi, it seems that the Ubuntu issue is solved, see https://travis-ci.org/antlr/antlr4/builds/218514385. Great! 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! |
@ericvergnaud looks like it still times out on Mac. should I wait to merge? |
Yes, I believe the solution is at hand, + we need the assembly to be renamed
Envoyé de mon iPhone
… Le 17 avr. 2017 à 01:14, Terence Parr ***@***.***> a écrit :
@ericvergnaud looks like it still times out on Mac. should I wait to merge?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.
|
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? |
unfortunately that is probably a limitation of C++ :( |
@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/ |
Well we can’t use « netstandard » because the regular version uses Antlr4.Runtime.Standard
And all nuget is about .Net so really don’t need net in the suffix.
Plus we need to cater with all the stuff published by Sam
So please stick to Antlr4.Runtime.Core which expresses the difference with Antlr4.Runtime.Standard i.e. .Net Core vs .Net Standard
… Le 25 avr. 2017 à 23:30, Dong Xie ***@***.***> a écrit :
@ericvergnaud <https://github.com/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/ <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.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub <#1810 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ADLYJJsLge7jeloQ9P27KRcYlrEAlLvgks5rzhGdgaJpZM4MzDTn>.
|
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