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.

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

[compatibility] update of libusb #895

Merged
merged 8 commits into from Apr 2, 2020

Conversation

slyshykO
Copy link
Collaborator

No description provided.

@Nightwalker-87 Nightwalker-87 self-requested a review March 25, 2020 12:03
@Nightwalker-87 Nightwalker-87 added this to the v1.6.1 milestone Mar 25, 2020
@Nightwalker-87 Nightwalker-87 added this to In progress in Release v1.6.1 via automation Mar 25, 2020
@Nightwalker-87
Copy link
Member

Oh, jolly good! I planned to take action on this topic as well. :-)

What is the reason for raising to the latest release available?
Are there any troubles with earlier versions? (I'm thinking about compatibility here).
Should we raise version requirements for unix-based systems as well?
Let me check the current libusb package versions for the most common distributions.

Whatever, we also need to update the documentation together with this change.
As far as I can see this affects /doc/compiling.md.

@Nightwalker-87 Nightwalker-87 moved this from In progress to Review in progress in Release v1.6.1 Mar 25, 2020
@slyshykO
Copy link
Collaborator Author

This is not obligatory changes. They apply only in a rare case when building for windows and libusb not found. For example in CI.
I think at this point of time no need to increase the requirement for libusb versions.

@Nightwalker-87
Copy link
Member

Nightwalker-87 commented Mar 25, 2020

Ok, let me check currently supplied libusb versions from the repos.

I think that we should set the version requirement in such a way that the oldest currently supported operating system versions of common linux/unix distributions are capable of running our stlink tools. This would also define the oldest libusb version to support (unless there is a bug that causes problems of course). I don't assume it to be a good idea to define different libusb versions for different OSs, as it likely raises confusion...

To be continued in #897 ...

@Nightwalker-87
Copy link
Member

Hi there, moved out the started discussion to #897 including all replies. Please continue there otherwise this PR is recycled for a basic discussion of this topic. Cleaning this up now.

@stlink-org stlink-org deleted a comment from Vascom Mar 26, 2020
@stlink-org stlink-org deleted a comment from slyshykO Mar 26, 2020
@stlink-org stlink-org deleted a comment from Vascom Mar 26, 2020
@stlink-org stlink-org deleted a comment from slyshykO Mar 26, 2020
@stlink-org stlink-org deleted a comment from Vascom Mar 26, 2020
@Nightwalker-87 Nightwalker-87 linked an issue Mar 26, 2020 that may be closed by this pull request
@Nightwalker-87
Copy link
Member

For windows the workflow could look like this:

  • check if libusb is present:
    • [case 1]: yes --> which version? --> < 1.0.20 ? --> ignore present and install 1.0.23 (newest)
    • [case 2]: yes --> which version? --> >= 1.0.20 ? --> use present
    • [case 3]: no: install 1.0.23 (newest)

The version which serves as the condition should be 1.0.20 for now, with the option to raise it at a later time (but then synchronous with the requirement for linux-based systems as proposed in #897).

@Nightwalker-87 Nightwalker-87 linked an issue Mar 27, 2020 that may be closed by this pull request
@Nightwalker-87 Nightwalker-87 changed the base branch from develop to ext_pkg_versions March 27, 2020 16:08
@Nightwalker-87
Copy link
Member

Feel free to extend this PR with related stuff, I'll leave it open for another while, but will submit own changes afterwards.

CMakeLists.txt Outdated Show resolved Hide resolved
@lhondareyte
Copy link
Contributor

That's ok for me : limits.h include sys/limits.h.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.