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

CMakeLists.txt: Provide libmraa rpm packaging support #952

Open
wants to merge 1 commit into
base: master
Choose a base branch
from
Open

CMakeLists.txt: Provide libmraa rpm packaging support #952

wants to merge 1 commit into from

Conversation

ghost
Copy link

@ghost ghost commented Feb 5, 2019

Yocto recipes manage all packages as RPMs. This patch enables rpm
packaging for libmraa that can be used in the Yocto flow.

Signed-off-by: Sai Hari Chandana Kalluri [email protected]

Yocto recipes manage all packages as RPMs. This patch enables rpm
packaging for libmraa that can be used in the Yocto flow.

Signed-off-by: Sai Hari Chandana Kalluri <[email protected]>
@tingleby
Copy link
Member

tingleby commented Feb 6, 2019

Thanks for the PR! I am not a big user of Yocto but would you not normally package using 'make install' /install target from CMake then the Yocto/Bitbake stage handle the RPM creation?

@ghost
Copy link
Author

ghost commented Feb 7, 2019

@tingleby The do_install task in bitbake copies the built files along with their hierarchy to locations that would mirror their locations on the target device. The installation process copies files from the work and build directories to the ${D} directory to create the structure as it should appear on the target system.

For the software to be installed correctly, it depends on how the software is built and the build system being used. If the Yocto recipe builds using Autotools or CMake, the Yocto OpenEmbedded build system understands how to install the software. Consequently, you do not have to have a do_install task as part of your recipe. However, if you wish to install additional files not already being installed by make install, you should do this using a do_install_append function using the install command.

In short, Yocto thinks that libmraa which uses CMake already creates the RPMs. If the lines of code from the PR are not included, the RPMs will not be created in the Yocto flow.

@arfoll
Copy link
Contributor

arfoll commented Feb 8, 2019

Cpack isn't used in the cmake bbclass? Why would any of these change anything?

@alext-mkrs
Copy link
Contributor

alext-mkrs commented Feb 9, 2019

In short, Yocto thinks that libmraa which uses CMake already creates the RPMs. If the lines of code from the PR are not included, the RPMs will not be created in the Yocto flow.

@ckalluri, that's a bit strange, at least with the opkg packages (and to the best of my recollection DEB/RPM as well, though it's a bit fuzzier) nothing additional was ever necessary. My understanding that it's namely as @tingleby described, Yocto creates RPMs on its own, not relying on the application's CMake targets beyond install, by doing the install and then collecting and packaging the produced files and dirs. Which Yocto version do you have and what mraa recipe(s) do you use?

ADDED LATER: I've just specifically checked the cmake.bbclass on Thud (but looking at git history for the file, the logic hasn't really changed in years) and it runs through configure, compile and install, doesn't really use the CMake's RPM generation facilities. So I'd presume you have some specifics in your Yocto environment causing the need for those changes?

@tingleby
Copy link
Member

Yeah it would seem what Id assume from experience with Debian packaging, using the Debian tool-set that the project itself doesn't need to be aware of Distro packaging.

I did a quick build of Poky and using the mraa recipe from meta-oe/recipes-extended/mraa I was able to get several RPMS from it :/

@alext-mkrs
Copy link
Contributor

Okay, thanks Tom. @ckalluri, please clarify why you need this, otherwise I'd personally be inclined to reject this for no good justification.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants