allow overriding PREFIX and VERSION for packagers

lifanov commented 5 years ago

Proposed changes

I'm making a FreeBSD package and this is all that's needed to make OpenCorsairLink to work as-is with my H115i.

Users must be able to override PREFIX and it's useful to generate a VERSION during build without git command or metadata being available.

This will benefit packagers for other operating systems too.

Types of changes

What types of changes does your code introduce to Appium? Put an x in the boxes that apply

[ ] Bugfix (non-breaking change which fixes an issue)
[x] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)

Checklist

Put an x in the boxes that apply. You can also fill these out after creating the PR. If you're unsure about any of them, don't hesitate to ask. We're here to help! This is simply a reminder of what we are going to look for before merging your code.

[x] I have read the CONTRIBUTING doc
[x] Make sure you are requesting to pull a topic/feature/bugfix branch (right side). Don't request your master!
[x] Make sure you are making a pull request against the testing branch (left side). Also you should start your branch off our testing.
[ ] Lint and unit tests pass locally with my changes
[ ] I have added tests that prove my fix is effective or that my feature works
[ ] I have added necessary documentation (if appropriate)
[x] Any dependent changes have been merged and published in downstream modules
[x] Check the commit's or even all commits' message styles matches our requested structure.

Further comments

Thanks for contributing!

audiohacked commented 5 years ago

The git tag is integral to issue reporting. Rejecting due to changes that would make my life harder.

jonasmalacofilho commented 5 years ago

@audiohacked

Actually not really, IMHO.

If you have the exact version of an official package, you can easily find out the corresponding version of the sources. I mean, at least on Linux distros, but I'm guessing it shouldn't be any different on FreeBSD.

Additionally, I find that having the package version helps to debug distro or kernel specific issues.

jonasmalacofilho commented 5 years ago

(off-topic)

@lifanov

Can you point me to the appropriate documentation and resources for packaging software for FreeBSD?

Specifically interested for a Python program that also depends on libusb, and also on hidapi.

audiohacked commented 5 years ago

@jonasmalacofilho First of All, OpenCorsairLink deals with a moving target in terms of hardware support. If everyone is waiting for a "stable" release, you're not going to get it because I'm the only one doing all the work. I've haven't had many, if anyone, step up and help with development. As soon as I get some serious contributors we can revisit this issue.

audiohacked commented 5 years ago

I will add more here. I don't want people changing the VERSION or the PREFIX which will make it harder to trust which version the issue is about. I can vouch that a certain Distro likes to change the version string to suit their needs on prior FOSS projects I've worked on the past 20 years. I am making decisions that make it easier for me (and right now only me) to support my users.

jonasmalacofilho commented 5 years ago

@audiohacked, fair enough.

(I did start my comment with IMHO... and only mentioned anything at all precisely because I deal with similar problems, yet not all breakage I see comes from hardware changes... still, fair enough)

I can continue to help with the (now old) Asetek coolers, and maybe also with some stuff related to the HXi/RMi PSUs. Feel free to ping me on issues about these.

audiohacked commented 5 years ago

@jonasmalacofilho Thanks! Your help so far has been great.

audiohacked / OpenCorsairLink