-
Notifications
You must be signed in to change notification settings - Fork 69
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
Support netstandard #78
Comments
Let me know if I can help with this in any way (testing / fixing). We are using FsLexYacc.Runtime in a netcore application and it runs ok with 461 but lots of warning messages and it would be great to have a clean netstandard api. This is one of the last dependencies we have for net461 right now. |
Any updates? |
@daz10000 have you gotten lexyacc to work with dotnet SDK projects? |
It works with net core SDK. <Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
<TargetFramework>netstandard2.0</TargetFramework>
<NoWarn>NU1701</NoWarn>
</PropertyGroup>
<ItemGroup>
<Compile Include="AlgTypes.fs" />
<FsYacc Include="AlgParser.fsp">
<OtherFlags>--internal --module Internal.Parser</OtherFlags>
</FsYacc>
<Compile Include="AlgParser.fs" />
<FsLex Include="AlgLexer.fsl" >
<OtherFlags>--unicode</OtherFlags>
</FsLex>
<Compile Include="AlgLexer.fs" />
<Compile Include="Alg.fs" />
</ItemGroup>
<ItemGroup>
<PackageReference Include="FsLexYacc" Version="7.0.6" />
</ItemGroup>
</Project> Adding <NoWarn>NU1701</NoWarn> disables the warning and everything compiles cleanly. |
Thanks, @mrgleba Prior to dotnet SDK this worked for me:
Changing it to |
It does work, it just spews warnings, but with the NOWARN tip above - thanks! my activation energy for fixing this just went down a lot. It does mean your whole project has warnings off though so a clean dotnet core version would be preferable. |
No, my old style reference totally did not work for me. The dotnet build just errored on the Parser fs and fsi and lexer fs missing. Using |
What exactly needs to be fixed? |
I think minimally Separately the tools could be made |
apparently I had no problem using the current runtime in a netcoreapp2.1 app |
As per @jackfoxy's comment, the reason that When using (Personally we would prefer to use |
@manofstick, just FYI, http://msbuildlog.com/ is an amazing tool to diagnose problems like this. Just wondering, you mention you prefer "classic" |
Maybe a bit archaic, but we just have a network share with all our third party references on it, grown over about 2 decades. With old style references this works well. Suggestions? |
@manofstick, I am not sure I understand the context. New style NuGet scripts are sloppy at times, I wish they could be better, and its build tasks are quite opaque and rigid. With the SDK projects there are also inner/outer builds, when the outer build phase essentially invokes the same project once per target framework. This also often requires subtle handling when dealing with codegen tools like fslex/fsyacc, which you might want to invoke only once per overall build, not once per target framework. What if you hook up using BeforeTargets instead of augmenting the |
@kkm000 I think this can be closed. |
The runtime now targets .NET Standard 2.0. |
Right now only net461 is targetted.
It would be nice to have a netstandard[something] build.
The text was updated successfully, but these errors were encountered: