-
Notifications
You must be signed in to change notification settings - Fork 1.2k
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
Update for package distribution #955
Conversation
- New cpack package-config for DEB and RPM - Toolchain file for cross-building - Script to automate MinGW cross-building - Added file headers for .cmake files - Added dpkg and rpm to required pkgs
- Added builds for clang -m32 on arch: AMD64 - Corrected invalid config settings - Added clang-9 builds for linux - Moved scripts to root directory - Added MinGW cross-test-build for linux
- Updated steps for release preparation - Changed destination for binary archives (Closes #798)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It is Ok for me
Wait - it's not ready yet ... 👀 |
Something else planned? |
Only some minor fixes, that's why I opened a draft PR. |
As @slyshykO reported, there is still an issue with a static linking to libssp on Windows when the binary package is generated via a debian cross-build which is not as expected. This needs a fix. When building natively on Windows this issue does not occur, as I could verify by myself on a virtual machine. As of the current state of knowledge I can't make out any difference in the related cmake compilation routine in If the reason is not found and nobody else is going to show any interest in this, cross-building for Windows will only generate non-functional binaries and thus will be useless... |
7faf9b1
to
cde5a97
Compare
- Simplified code - Added version info for static library
- Added package changelog files for deb & rpm - Added license file for deb pkg - Added rules file for deb pkg - Changed install subdirectory
@Vascom: How can we make the rpm package relocatable (universal)? I found there are still a few minor issues related to this for our package:
This relates to the following files: /$USER-PATH$/stlink/build/Debug/install/etc/modprobe.d/stlink_v1.conf Do you or anyone else have an idea? It would be a nice to have, I think. |
It is bad idea to have one rpm package for many distros. All of them has differencies and this work should be done by maintrainers. |
Well they can do as they like, but I am not willing to generate several rpm packages for a project release. Thus this package should be widely deployable. |
You can not generate any. |
We already do - with cmake ;-) |
- Removed unneeded commands in travis.sh - Removed -Wno-dev flag in Release target - cmake: Grouped udev and modprobe.d config - rpm package now relocatable (CPackRPM)
@slyshykO @chenguokai: These were the outstanding changes still missing to conclude this PR. |
I mean do it properly as every distro recommend and require. |
That's why there are package maintainers, but that should not prevent us from providing a general-use rpm package here on our GitHub release page, as we do provide one for debian-based systems. Can we conclude this topic now? This is also not the right place to discuss this, BTW. |
Yes. |
ef8522f
to
a937f9e
Compare
Tidy up install paths & directories: -> modprobe.d & udev rules (both are now ON per default on Linux) -> stlink-gui supplements -> man pages - Fixed paths according to GNUInstallDirs - cmake: Restructured library config - Test files & gui now use shared library
@chenguokai Can you give it a test again on macOS? I've successfully compiled, installed and used the toolset executables on debian. If there are no further significant issues I'd like to merge this PR now. It has become quite bulky already. |
@Nightwalker-87 |
Oh that is good news - I'm surprised it is achievable that easy. I tried that argument somewhere else before, what didn't work. Ok - wait let us finish and merge this PR first. Yours should follow subsequently then. |
Looks easy but I, like you, tried many times before getting success on build :) |
Edit: the first one is resolved on develop branch so not a problem actually. The below one, in my view, can be ignored for now. I will take care of it after merge. Mostly good with one problem. 1.. cmake failed with with a simple version bump in MacPorts Portfile
The one could not be a problem since I only checked out |
|
Thank you both @chenguokai & @slyshykO for reviewing this. 🥇 |
Finally I figured out the problem here. Might be a MacPorts specific issue with one cmake flag set like Edit: Not triggered by this, I forgot to remove my local modification before testing😅 Maybe we should ignore any external CMAKE_MODULE_PATH. |
That will likely help... 😄 |
Changes & additions:
--> Added builds for clang -m32 on arch: AMD64
--> Corrected invalid config settings
--> Added clang-9 builds for linux
--> Moved scripts to root directory
--> Added MinGW cross-test-build for linux
-> modprobe.d & udev rules (both are now ON per default on Linux)
-> stlink-gui supplements
-> man pages