Closed bentorkington closed 2 years ago
Thanks, this looks great, I will work through it in detail this evening. It’s probably a good idea for me to try and get it working locally as well.
I can run dotnet build
but dotnet test
results in the following error. Thought I should check before making any big assumptions about installing or uninstalling everything.
My assumption is that the config somewhere in the project is expecting a different framework version, and maybe that can be updated. I know the way I had things originally was pretty poor—just dumping a bunch of dependencies into a folder, rather than installing them via a package manager, but it was the first time I had made anything in C# beyond hello world and I found getting the project set up much more difficult than actually writing the code.
I don't blame you. I had a similar time just today when testing the DLLs I created can indeed be executed by Unity, and found I needed to target specifically .NET Standard 2.0
I blindly converted the test suite to use the same framework, found that NUnit won't run against Standard, and I somewhat arbitrarily chose .NET Core 3 (which apparently I have installed but you don't). I'll see if the test suite can run under 6, but we definitely can't build Calyx for Unity with 6
… done, tests seem to work everywhere while targetting .NET 6, so this should be work for you now.
I upgraded to Monterrey recently (I had been holding out as I had so much stuff working that I didn’t want to break, but the Xcode drift became too much and Apple started locking me out of features). Broke everything, I had to recompile basically my entire dev environment, and still running up against problems even today I had to reinstall Ruby from source with a bespoke flag because some weird recent Xcode/Clang interactions broke gem installs that had C extensions.
So far the dotnet
tools feel less janky and far better documented than the previous hacks I had set up though.
👍 All seems to be working now, tests are running and passing. Glad I was actually correct in my assumption.
To answer one of the previous questions in general, I think the approach of seeding is probably the right one in almost every case. Unless we run into xplatform issues (I haven’t so far in other languages), it is a lot easier to understand and read the tests when they are fully deterministic and check a single result, rather than trying to test a state space (eg: like the following).
Complete @maetl's work in accordance with #4
Because I kept having issues getting the build to work with current toolchains, and didn't want to waste @maetl's work already done, the project was also extensively reworked in this branch