Comments (13)
As ETH supports fedora as the official Linux version, I am willing to give rpm a try for 1.3.1, anyway it cannot be as ugly as Debian packages... After having a quick look on the net, it seems it is not. We could then try to build on SUSE open build service.
Any advice/good place to look for tutorials on how to create spec files? I have found http://docs.fedoraproject.org/en-US/Fedora_Draft_Documentation/0.1/html/Packagers_Guide/sect-Packagers_Guide-Creating_a_Basic_Spec_File.html until now.
from aseba.
have a look here: https://fedoraproject.org/wiki/Packaging:Cmake for the cmake-specific information
But you will need to package dashel first.
from aseba.
Once done, I would like to store the .spec
file in the git tree, is there a best-practice directory to put it to? Maybe rpm/
?
from aseba.
well, no. There is no "best-practice" as most of the time, distributions keep the spec file outside of the package in their own svn/git repository.
from aseba.
I've built SRPMS and x86_64 RPMS for aseba, enki, and dashel on my Fedora 20 system and added them to the download page. [Edit: removing obsolete link to Google Drive files].
The enki and dashel packages include patches required to build them as shared libs and install those libs in /usr/lib64 instead of /usr/lib. I'll try to get pull requests together for those changes soon or you can access the patch files by installing the SRPMS.
BTW, for the aseba package, I only install the files that are installed by the debian package. Doing 'make install' normally installs a bunch of other files including extra executables and libs/headers needed to build the executables. Can/should the CMakeLists.txt files be changed to not actually install those files?
from aseba.
Hi Dean,
Thank you very much for your contributions. I would be happy to apply your patches upstream to Enki and Dashel.
About the Aseba package, yes "make install" also installs files required to use Aseba as a library. I understand that you would prefer it to install only the user part of Aseba. I do not know if there is a clean way to have something like "make devinstall" with CMake, maybe with an option?
So you packaged 1.3.1, not 1.3.2rc?
from aseba.
I think the make install is correct, the .spec file should simply split the binaries from the development headers and provide a -devel package.
from aseba.
I packaged the 1.3.x branch from github as of a couple days ago (which I assume is 1.3.2rc). The "-1" part of the package name is the RPM release number. Packagers are suppose to bump that whenever the spec file is modified.
I'll add an aseba-devel package for the other stuff that is installed by "make install". Fedora guidelines seem to indicate that the examples directory should just be copied to /usr/share/doc/aseba-devel/examples in source form. That OK? If not, I think that qt-gui should be renamed to something like asebaqt-gui.
from aseba.
Copying examples to /usr/share/doc/aseba-devel/examples is fine for me.
Could you please upload your packages to https://aseba.wikidot.com/en:linuxinstall? Anyone who is a "member of the site" can upload page. Becoming a member is a one-click process.
from aseba.
Done. I should have thought of that earlier, since I'd made edits before...
I'll work on putting together pull requests for my patches and to add rpm folders with the spec files and a README.
An important note: The RPMS install shared libraries. If you make changes to a library that break ABI compatibility (which is easy to do by accident in C++), you need to bump the library's major version number. It is set via:
set(LIB_VERSION_MAJOR 1) # Must be bumped for incompatible ABI changes
in the CMakeLists.txt file that is in or above the directory containing the library source.
from aseba.
Thanks a lot! I have updated the download page to make your packages more visible: https://aseba.wikidot.com/en:linuxinstall
Dashel should not receive ABI-breaking changes, but Enki certainly will. I will try not to forget to update the library version. That said, I thought the proper CMake command was set_target_properties(${LIB_NAME} PROPERTIES VERSION "${PROJECT_VERSION}" SOVERSION 1)
from aseba.
Your welcome, and thanks for all of your work on Aseba, Dashel, and Enki. My son is really enjoying programming his Thymio. :-)
Regarding SOVERSION, my patch uses:
set(LIB_VERSION_MAJOR 1) # Must be bumped for incompatible ABI changes
set(LIB_VERSION_MINOR 0)
set(LIB_VERSION_PATCH 7)
set(LIB_VERSION_STRING
${LIB_VERSION_MAJOR}.${LIB_VERSION_MINOR}.${LIB_VERSION_PATCH})
set_target_properties(dashel PROPERTIES VERSION ${LIB_VERSION_STRING}
SOVERSION ${LIB_VERSION_MAJOR})
You could bump the SOVERSION without bumping major package version if you wanted to track API and ABI compatibility separately but I figured that would be unnecessarily confusing.
BTW, I just noticed that all the packages I've produced thus far have a bug where they used SO_VERSION (which does nothing) instead of SOVERSION. As a result they require specific versions of each other and need to be updated in unison. I'll get that fixed right away...
from aseba.
As the RPM package is now maintained by @brettle, I close this bug.
from aseba.
Related Issues (20)
- asebastudio arguments
- Contact with the Aseba community HOT 2
- BCU lausanne: instabilité de l'interface Aseba Studio HOT 2
- Asebamedulla missing in build HOT 2
- Ambiguous native function descriptions HOT 4
- Issue connection with the new Blockly WEB HOT 1
- Aseba's Examples' Documentation
- Aseba Studio missing in Ubuntu 18.04 HOT 9
- Program Thymio II with buttons and an array (delay-problem?) HOT 2
- asebastudio crashes when text is typed HOT 2
- Problem to compile a deb package of aseba HOT 25
- Python3 compatibility HOT 1
- asebamedulla on macOS
- asebastudio crashes on fedora HOT 2
- How to connect Multiple Robots from playground to studio HOT 2
- aseba compilation issue on raspberry HOT 3
- Issu in compiling ASEBA under Ubuntu 18.10 with new repository
- Update of Aseba protocole HOT 9
- Aseba studio on Ubuntu 20.04 HOT 1
- build failed on gcc-13
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from aseba.