qskinny icon indicating copy to clipboard operation
qskinny copied to clipboard

No install targets

Open schnitzeltony opened this issue 6 years ago • 5 comments

I am working on qskinny cross build with Openembedded/Yocto [1-2]. I think compiling works fine (had to inject qemu to make cross svg2qvg run) Now I see that there are no install targets in Makefiles created. I could install manually the files created in build folder but that is error prone... Any hints how to get qmake create install targets?

[1] https://www.yoctoproject.org/ [2] https://github.com/schnitzeltony/meta-qt5-extra/tree/qkinny-wip

schnitzeltony avatar Oct 16 '18 15:10 schnitzeltony

svg2qvg is usually never used on the target device. It is a tool, that translates SVG into a sequence of QPainter commands, so that this does not need to be done at runtime. The situation is similar to moc and maybe you could treat it similar.

Concerning the install targets: in Qwt I have a qwtconfig.pri file with default install paths, that is supposed to be adjusted by the user. How is this handled in other projects - do you know some sort of common way to do this ?

In the end there are a few libs and headers to be installed + a couple of plugins( skins and the inputcontext ), that need to go to a specific path, where it can be found by Qt.

Not sure about the executables from examples/playground - with Qwt I don't any examples. At least there is no QML extra code to install as everything is compiled into the examples as qrc files.

I also didn't write a qskinny.prf file yet so that user code could simply write:

CONFIG += qskinny

If you like you can contact me by Email ( your nickname indicates some skills in German :-) ) and we can do this step by step together ?

uwerat avatar Oct 16 '18 15:10 uwerat

Thanks for prompt response and offering 'private' support. I suggest to continue here to protect you from others asking same questions again :)

svg2qvg is usually never used on the target device. It is a tool, that translates SVG into a sequence of QPainter commands, so that this does not need to be done at runtime. The situation is similar to moc and maybe you could treat it similar.

What about projects using qskinny? They might want to compile in svgs too

For installation I see two ways to go:

  1. The Qwt way adding a pri file with installation path defaults (simple - will try that first)
  2. The way Qt-core libraries are build - see (outdated) [1]. The advantage is that that creates all the simple Q-headers and packs properly. Have done that in some of my projects e.g [2]. Problem is that this is a bit of voodo magic...

So I'll try 1. and come back then.

Thanks again

[1] https://wiki.qt.io/Creating_a_new_module_or_tool_for_Qt [2] https://github.com/schnitzeltony/qtiohelper

schnitzeltony avatar Oct 17 '18 09:10 schnitzeltony

Concerning svg2qvg: of course it is intended to be used by projects using qskinny. But it is part of the build process, so it needs to be available on the system, where you build the project - not the one you are cross compiling for.

I changed the implementation of svg2qvg, so that it is including the files it needs from qskinny instead of linking the library. This way it is possible to cross compile qskinny applications without having to build the qskinny library for the build environment first. Of course you still need to build svg2qvg first.

uwerat avatar Oct 23 '18 05:10 uwerat

Saw your changes for svg2qvg - thanks for taking care. Unfortunately it is qtsvg: That requires native qtbase build with gui (and / or widgets - don't remember exactly). Openembedded's native qtbase is build without these build options and I tried: It is not a trivial task to change that.

Whatever: The qemu solution works: qskinny examples run perfectly fine on my RaspberryPi 2 since few minutes!

To make binaries install I created a patch [1]. Don't want to send it out here like this because it installs plugins (skins) in libdir due to hard linked plugins. Will work on this further...

[1] https://github.com/schnitzeltony/meta-qt5-extra/blob/master/recipes-misc/recipes-graphics/qskinny/qskinny/0001-Add-installation-targets.patch

schnitzeltony avatar Oct 24 '18 14:10 schnitzeltony

I added install rules, but did not follow exactly your patch:

a) as I don't like projects myself, that mix up with installations of other projects I added a different default install root - on unix systems it will be /usr/local/qskinny-x.y.z

b) I removed the RPATH directives and linked in dependencies between libraries

c) plugins ( skins, inputcontext ) need to go to specific subdirectories - otherwise the mechanism of Qt for loading plugins does not work.

d) examples/playground are not installed - IMO the value of them is the source code. Not installing them allows to make use of RPATH for them, what simplifies the situation for users who only want to check QSkinny before making a decision to install.

e) I added some qmake functions ( qskfunctions.pri ) to cover the different naming rules for libraries on different platforms.

What is missing:

  • qskinny.prf, so that user project files can do: CONFIG += qskinny
  • pkgconfig support
  • as I don't have a Mac: handling of frameworks

Concerning svg2qvg:

our application using QSkinny has > 1000 different icons ( SVG ) and precompiling them into QPainter commands ( that is what svg2qvg does ) makes a lot of sense for performance reasons.

Using vector gaphic formats ( like qvg ) allows to have the same icons on devices with different resolutions and form factors. It also allows for color substitutions, what is used for implementing daylight/darkness modes without having to have different sets of icons. Finally those substitutions also allow for smooth transitions for state depending color changes ( f.e enabled/disabled ).

So QSkinny does not depend on vector graphic formats, but it can make use of them in a way, that I would recommend to always use SVGs instead of raster graphic formats. But because of svg2qvg there is never a runtime dependency for qtsvg.

uwerat avatar Oct 25 '18 08:10 uwerat

Looks like install rules are working now since the switch to cmake

peter-ha avatar Jul 05 '23 14:07 peter-ha

Yes and no - the cmake scripts that help projects to find and use QSkinny are not implemented and therefore not part of the installation ( similar to what an installed qskinny.prf files would offer for qmake users ).

uwerat avatar Jul 05 '23 15:07 uwerat

cmake install is complete now.

uwerat avatar Jan 16 '24 13:01 uwerat