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.

Sign up for GitHub

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

Jump to bottom

Development on Windows #368

Closed
Tastaturtaste opened this issue Oct 5, 2023 · 2 comments
Closed

Development on Windows #368

Tastaturtaste opened this issue Oct 5, 2023 · 2 comments

Comments

@Tastaturtaste
Copy link
Contributor

Tastaturtaste commented Oct 5, 2023 •
edited
Loading

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.
@Tastaturtaste Tastaturtaste reopened this Oct 5, 2023
@Tastaturtaste Tastaturtaste mentioned this issue Oct 7, 2023
Merged
stefan-k pushed a commit that referenced this issue Jan 14, 2024
@Tastaturtaste @stefan-k
Factored out argmin-math tests into separate package
3174127 
Due to the additivity requirement on cargo features even for features
that are not enabled simultaneously, together with the requirement that
only one crate in the dependency tree specifies any `links` attribute,
it was not possible to test multiple backend versions for ndarray-linalg
by features: #368 (comment)
Previously this approach worked for different versions of
ndarray-linalg insofar as the used backend `netlib` just coincidentally
remained the same for all tested ndarray-linalg versions.
This is not the case for the intel-mkl backend, which is desirable to
use as the default because it works on all three major platforms. To
enable the change of the backend as well as make the testing more
robust against future changes in ndarray-linalg backend versions, the
tests were factored out into their own crates. This works because the
strict additivity requirement for inactive features is not enforced for
dependencies: rust-lang/cargo#5969 (comment)
@stefan-k
Copy link
Member

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
Copy link
Contributor Author

Yes, this issue is resolved now

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@stefan-k @Tastaturtaste