Development on Windows

[Tastaturtaste]

This issue is intended as documentation for the blockers of development on Windows.

The Problem

1. Compiling and running the tests requires ndarray-linalg with choice of backend
2. Currently the backend specified is netlib
3. netlib is only available on linux
4. An alternative backend available on all three major platforms would be intel-mkl
5. Replacing netlib with intel-mkl results in link errors during dependency resolution. This is because multiple features to select different versions of ndarray-linalg are available for testing purposes in argmin-math. However, different versions of ndarray-linalg with the intel-mkl feature would link against different versions of intel-mkl-src, each with the same links tag in their Cargo.toml. Since each test configuration only ever depends on one version of each dependency, this wouldn't be a problem if it weren't for this issue resulting from the additivity requirement on features, even if they are not active. This is not an issue for the netlib-src sub-dependency right now since it hasn't been updated in between different versions of the tested dependencies. As such, all tested versions of the dependencies resolve their netlib-src version to the exact same version, which then does not result in multiple links tags with the same value in the Cargo.lock file.

Possible solutions/workarounds

1. A quite boilerplate intensive workaround for testing a crate with this problem is described in the issue linked above. It involves creating a crate for each feature combination in a different workspace than the problematic library. This works because, in contrast to the tested crate itself, dependencies are only checked for conflicts with actually used features. With this approach, it is however impossible to test private implementation details, as they are not exposed to dependents.
2. Test only dependencies with a fixed version of intel-mkl, which currently would mean with only one version of ndarray-linalg

Since I lost much more time than anticipated in this rabbit hole after I got asked if I wanted to do a PR, I at least wanted to document what I found out. I want to emphasize that I absolutely did not feel pressured to spend this time, @stefan-k has been very forthcoming and respectful in all interactions. For me, it was quite non-obvious why I got links resolver errors when I just changed the dev features from one backend to the other with references to features I had disabled. Apparently, cargo tree also doesn't work on this "broken" dependency tree.

[stefan-k]

I'm very happy that argmin now supports development on windows! Thanks yet again for the amazing effort and the patience. Am I missing something or can this be closed?

[Tastaturtaste]

Yes, this issue is resolved now