NetCube-Systems-Austria/kumquat-buildroot
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
ecec8f8f32
kumquat-buildroot/docs/manual/adding-packages-qmake.adoc

84 lines
2.8 KiB
Plaintext
Raw Normal View History

package/pkg-qmake: new qmake package infrastructure This provides generic functions for Qt5 qmake based packages. It will make it possible to remove lots of redefinition of QT5_xxx_{CONFIGURE|BUILD|INSTALL_STAGING}_CMDS. Additionally it provides a generic target install method which will make most of the package specific commands obsolete. This is done by re-running the install step of the qmake generated Makefile with the package build directory prepended (to the staging/host path). Even though this does create lengthy pathes it allows for easy separation of the staging files from the host destined files by just omitting the resulting BUILD_DIR+HOST_DIR path from the following rsync call to the real target folder. The cleanup of many files we dont want in target is deferred to the target-finalize step. In addition to what's being removed already, we also have to cleanup some Qt5 specific files (prl) and the documentation directory. This approach was chosen over copying all files recorded in the pkg-files-list after some discussion which Thomas Petazzoni summed up: "We don't yet use pkg-files-list really as part of the build process anywhere, I feel a bit more comfortable at this point with what Andreas is proposing." Thanks to this infrastructure, it will be possible to get rid of the many conditional install commands because qmake already takes care of this when generating the Makefile install targets with the given or autodetected configure options of each package. However, custom install steps may have to remain in cases where a particular Buildroot option has no corresponding setting in the packages configuration options. Signed-off-by: Andreas Naumann <anaumann@ultratronik.de> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
2020-02-17 22:23:24 +01:00
// -*- mode:doc; -*-
// vim: set syntax=asciidoc:
=== Infrastructure for QMake-based packages
[[qmake-package-tutorial]]
==== +qmake-package+ tutorial
First, let's see how to write a +.mk+ file for a QMake-based package, with
an example :
docs/manual: normalize delimiters of listing blocks Although the asciidoc toolchain accepts any number of ~ to delimit a listing block (i.e. a code block), it is actually specified to be exactly four, i.e. ~~~~. Currently, a mix of diffrent numbers of ~ are being used - sometimes even a different number at the beginning and at the end of the block. Normalize this to always use exactly four ~ for the delimiter. Signed-off-by: Arnout Vandecappelle <arnout@mind.be> (cherry picked from commit 447fa1fca425e629cc65cd0a8261a4c09ddf67d2) Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2024-07-12 20:23:24 +02:00
----
package/pkg-qmake: new qmake package infrastructure This provides generic functions for Qt5 qmake based packages. It will make it possible to remove lots of redefinition of QT5_xxx_{CONFIGURE|BUILD|INSTALL_STAGING}_CMDS. Additionally it provides a generic target install method which will make most of the package specific commands obsolete. This is done by re-running the install step of the qmake generated Makefile with the package build directory prepended (to the staging/host path). Even though this does create lengthy pathes it allows for easy separation of the staging files from the host destined files by just omitting the resulting BUILD_DIR+HOST_DIR path from the following rsync call to the real target folder. The cleanup of many files we dont want in target is deferred to the target-finalize step. In addition to what's being removed already, we also have to cleanup some Qt5 specific files (prl) and the documentation directory. This approach was chosen over copying all files recorded in the pkg-files-list after some discussion which Thomas Petazzoni summed up: "We don't yet use pkg-files-list really as part of the build process anywhere, I feel a bit more comfortable at this point with what Andreas is proposing." Thanks to this infrastructure, it will be possible to get rid of the many conditional install commands because qmake already takes care of this when generating the Makefile install targets with the given or autodetected configure options of each package. However, custom install steps may have to remain in cases where a particular Buildroot option has no corresponding setting in the packages configuration options. Signed-off-by: Andreas Naumann <anaumann@ultratronik.de> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
2020-02-17 22:23:24 +01:00
01: ################################################################################
02: #
03: # libfoo
04: #
05: ################################################################################
06:
07: LIBFOO_VERSION = 1.0
08: LIBFOO_SOURCE = libfoo-$(LIBFOO_VERSION).tar.gz
09: LIBFOO_SITE = http://www.foosoftware.org/download
10: LIBFOO_CONF_OPTS = QT_CONFIG+=bar QT_CONFIG-=baz
11: LIBFOO_DEPENDENCIES = bar
12:
13: $(eval $(qmake-package))
docs/manual: normalize delimiters of listing blocks Although the asciidoc toolchain accepts any number of ~ to delimit a listing block (i.e. a code block), it is actually specified to be exactly four, i.e. ~~~~. Currently, a mix of diffrent numbers of ~ are being used - sometimes even a different number at the beginning and at the end of the block. Normalize this to always use exactly four ~ for the delimiter. Signed-off-by: Arnout Vandecappelle <arnout@mind.be> (cherry picked from commit 447fa1fca425e629cc65cd0a8261a4c09ddf67d2) Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2024-07-12 20:23:24 +02:00
----
package/pkg-qmake: new qmake package infrastructure This provides generic functions for Qt5 qmake based packages. It will make it possible to remove lots of redefinition of QT5_xxx_{CONFIGURE|BUILD|INSTALL_STAGING}_CMDS. Additionally it provides a generic target install method which will make most of the package specific commands obsolete. This is done by re-running the install step of the qmake generated Makefile with the package build directory prepended (to the staging/host path). Even though this does create lengthy pathes it allows for easy separation of the staging files from the host destined files by just omitting the resulting BUILD_DIR+HOST_DIR path from the following rsync call to the real target folder. The cleanup of many files we dont want in target is deferred to the target-finalize step. In addition to what's being removed already, we also have to cleanup some Qt5 specific files (prl) and the documentation directory. This approach was chosen over copying all files recorded in the pkg-files-list after some discussion which Thomas Petazzoni summed up: "We don't yet use pkg-files-list really as part of the build process anywhere, I feel a bit more comfortable at this point with what Andreas is proposing." Thanks to this infrastructure, it will be possible to get rid of the many conditional install commands because qmake already takes care of this when generating the Makefile install targets with the given or autodetected configure options of each package. However, custom install steps may have to remain in cases where a particular Buildroot option has no corresponding setting in the packages configuration options. Signed-off-by: Andreas Naumann <anaumann@ultratronik.de> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
2020-02-17 22:23:24 +01:00
On line 7, we declare the version of the package.
On line 8 and 9, we declare the name of the tarball (xz-ed tarball
recommended) and the location of the tarball on the Web. Buildroot
will automatically download the tarball from this location.
On line 10, we tell Buildroot what options to enable for libfoo.
docs/manual: fix typo depednencies -> dependencies Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com> Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
2020-08-22 21:20:01 +02:00
On line 11, we tell Buildroot the dependencies of libfoo.
package/pkg-qmake: new qmake package infrastructure This provides generic functions for Qt5 qmake based packages. It will make it possible to remove lots of redefinition of QT5_xxx_{CONFIGURE|BUILD|INSTALL_STAGING}_CMDS. Additionally it provides a generic target install method which will make most of the package specific commands obsolete. This is done by re-running the install step of the qmake generated Makefile with the package build directory prepended (to the staging/host path). Even though this does create lengthy pathes it allows for easy separation of the staging files from the host destined files by just omitting the resulting BUILD_DIR+HOST_DIR path from the following rsync call to the real target folder. The cleanup of many files we dont want in target is deferred to the target-finalize step. In addition to what's being removed already, we also have to cleanup some Qt5 specific files (prl) and the documentation directory. This approach was chosen over copying all files recorded in the pkg-files-list after some discussion which Thomas Petazzoni summed up: "We don't yet use pkg-files-list really as part of the build process anywhere, I feel a bit more comfortable at this point with what Andreas is proposing." Thanks to this infrastructure, it will be possible to get rid of the many conditional install commands because qmake already takes care of this when generating the Makefile install targets with the given or autodetected configure options of each package. However, custom install steps may have to remain in cases where a particular Buildroot option has no corresponding setting in the packages configuration options. Signed-off-by: Andreas Naumann <anaumann@ultratronik.de> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
2020-02-17 22:23:24 +01:00
Finally, on line line 13, we invoke the +qmake-package+
macro that generates all the Makefile rules that actually allows the
package to be built.
[[qmake-package-reference]]
==== +qmake-package+ reference
The main macro of the QMake package infrastructure is +qmake-package+.
It is similar to the +generic-package+ macro.
Just like the generic infrastructure, the QMake infrastructure works
by defining a number of variables before calling the +qmake-package+
macro.
docs/manual: standardize references to the generic infra Currently the text for each package infra that mentions the usage of variables already provided by the generic infra diverge from each other: - some (golang, kconfig, python) add a cross-referece to the generic infra chapter; - kconfig does not list any example; - some mention _LICENSE as an example, others don't; - some (cargo, golang, python) add an 'etc.' at the end of the examples, giving the idea that can be more symbols provided by the generic infra than the ones listed; - most have the text 'works by defining a number of variables before calling the +<macro-name>+ macro', except golang and kconfig; - some actually list 'A few additional variables' but keep using some old reference as 'An additional variable'; - some say 'First, all the package metadata' and other only 'All the package metadata'; - most mention _SUBDIR as an example of variable supported by the generic infra, even the generic infra manual not mentioning it. Improve the correctness for the manual by standardizing the text among the package infras: - use the same text "All the package metadata information variables that exist in the generic package infrastructure also exist in the <name> infrastructure:" for all of them; - add the cross-reference for all of them; - remove the examples of variables inherited from the generic infra - this also solves the _SUBDIR problem, there no longer is any reference to _SUBDIR; - wrap the modified text at 80 columns; - add "macro" to golang and luarocks infra; - use "A few additional variables" for qmake and waf. At same time, add a missing format on golang manual for BR2_PACKAGE_HOST_GO_HOST_ARCH_SUPPORTS. Cc: Eric Le Bihan <eric.le.bihan.dev@free.fr> Cc: Thomas De Schampheleire <thomas.de_schampheleire@nokia.com> Signed-off-by: Ricardo Martincoski <ricardo.martincoski@gmail.com> [Arnout: - remove the examples; - add "the" where "macro" was added; - rewrite the preceding paragraphs for kconfig to make it more consistent. ] Signed-off-by: Arnout Vandecappelle <arnout@mind.be> (cherry picked from commit 4286c89f9d987f5f3bcbb14dfd58ba440944f4c2) Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2023-01-02 00:36:53 +01:00
All the package metadata information variables that exist in the
xref:generic-package-reference[generic package infrastructure] also
exist in the QMake infrastructure.
package/pkg-qmake: new qmake package infrastructure This provides generic functions for Qt5 qmake based packages. It will make it possible to remove lots of redefinition of QT5_xxx_{CONFIGURE|BUILD|INSTALL_STAGING}_CMDS. Additionally it provides a generic target install method which will make most of the package specific commands obsolete. This is done by re-running the install step of the qmake generated Makefile with the package build directory prepended (to the staging/host path). Even though this does create lengthy pathes it allows for easy separation of the staging files from the host destined files by just omitting the resulting BUILD_DIR+HOST_DIR path from the following rsync call to the real target folder. The cleanup of many files we dont want in target is deferred to the target-finalize step. In addition to what's being removed already, we also have to cleanup some Qt5 specific files (prl) and the documentation directory. This approach was chosen over copying all files recorded in the pkg-files-list after some discussion which Thomas Petazzoni summed up: "We don't yet use pkg-files-list really as part of the build process anywhere, I feel a bit more comfortable at this point with what Andreas is proposing." Thanks to this infrastructure, it will be possible to get rid of the many conditional install commands because qmake already takes care of this when generating the Makefile install targets with the given or autodetected configure options of each package. However, custom install steps may have to remain in cases where a particular Buildroot option has no corresponding setting in the packages configuration options. Signed-off-by: Andreas Naumann <anaumann@ultratronik.de> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
2020-02-17 22:23:24 +01:00
docs/manual: standardize references to the generic infra Currently the text for each package infra that mentions the usage of variables already provided by the generic infra diverge from each other: - some (golang, kconfig, python) add a cross-referece to the generic infra chapter; - kconfig does not list any example; - some mention _LICENSE as an example, others don't; - some (cargo, golang, python) add an 'etc.' at the end of the examples, giving the idea that can be more symbols provided by the generic infra than the ones listed; - most have the text 'works by defining a number of variables before calling the +<macro-name>+ macro', except golang and kconfig; - some actually list 'A few additional variables' but keep using some old reference as 'An additional variable'; - some say 'First, all the package metadata' and other only 'All the package metadata'; - most mention _SUBDIR as an example of variable supported by the generic infra, even the generic infra manual not mentioning it. Improve the correctness for the manual by standardizing the text among the package infras: - use the same text "All the package metadata information variables that exist in the generic package infrastructure also exist in the <name> infrastructure:" for all of them; - add the cross-reference for all of them; - remove the examples of variables inherited from the generic infra - this also solves the _SUBDIR problem, there no longer is any reference to _SUBDIR; - wrap the modified text at 80 columns; - add "macro" to golang and luarocks infra; - use "A few additional variables" for qmake and waf. At same time, add a missing format on golang manual for BR2_PACKAGE_HOST_GO_HOST_ARCH_SUPPORTS. Cc: Eric Le Bihan <eric.le.bihan.dev@free.fr> Cc: Thomas De Schampheleire <thomas.de_schampheleire@nokia.com> Signed-off-by: Ricardo Martincoski <ricardo.martincoski@gmail.com> [Arnout: - remove the examples; - add "the" where "macro" was added; - rewrite the preceding paragraphs for kconfig to make it more consistent. ] Signed-off-by: Arnout Vandecappelle <arnout@mind.be> (cherry picked from commit 4286c89f9d987f5f3bcbb14dfd58ba440944f4c2) Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2023-01-02 00:36:53 +01:00
A few additional variables, specific to the QMake infrastructure, can
package/pkg-qmake: new qmake package infrastructure This provides generic functions for Qt5 qmake based packages. It will make it possible to remove lots of redefinition of QT5_xxx_{CONFIGURE|BUILD|INSTALL_STAGING}_CMDS. Additionally it provides a generic target install method which will make most of the package specific commands obsolete. This is done by re-running the install step of the qmake generated Makefile with the package build directory prepended (to the staging/host path). Even though this does create lengthy pathes it allows for easy separation of the staging files from the host destined files by just omitting the resulting BUILD_DIR+HOST_DIR path from the following rsync call to the real target folder. The cleanup of many files we dont want in target is deferred to the target-finalize step. In addition to what's being removed already, we also have to cleanup some Qt5 specific files (prl) and the documentation directory. This approach was chosen over copying all files recorded in the pkg-files-list after some discussion which Thomas Petazzoni summed up: "We don't yet use pkg-files-list really as part of the build process anywhere, I feel a bit more comfortable at this point with what Andreas is proposing." Thanks to this infrastructure, it will be possible to get rid of the many conditional install commands because qmake already takes care of this when generating the Makefile install targets with the given or autodetected configure options of each package. However, custom install steps may have to remain in cases where a particular Buildroot option has no corresponding setting in the packages configuration options. Signed-off-by: Andreas Naumann <anaumann@ultratronik.de> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
2020-02-17 22:23:24 +01:00
also be defined.
* +LIBFOO_CONF_ENV+, to specify additional environment variables to
pass to the +qmake+ script for the configuration step. By default, empty.
* +LIBFOO_CONF_OPTS+, to specify additional options to pass to the
+qmake+ script for the configuration step. By default, empty.
* +LIBFOO_MAKE_ENV+, to specify additional environment variables to the
+make+ command during the build and install steps. By default, empty.
* +LIBFOO_MAKE_OPTS+, to specify additional targets to pass to the
+make+ command during the build step. By default, empty.
* +LIBFOO_INSTALL_STAGING_OPTS+, to specify additional targets to pass
to the +make+ command during the staging installation step. By default,
+install+.
* +LIBFOO_INSTALL_TARGET_OPTS+, to specify additional targets to pass
to the +make+ command during the target installation step. By default,
+install+.
package/pkg-qmake: add <pkg>_SYNC_QT_HEADERS support Some qmake based packages need to call the syncqt.pl script before building to have a properly populated "include" directory inside the package build tree. This script is normally automatically executed by qmake when a source tree is from a git clone: buildroot purges the .git directory hence the script never runs, and we need to call it explicitly. Setting <pkg>_SYNC_QT_HEADERS = YES will force calling this script. Signed-off-by: Angelo Compagnucci <angelo@amarulasolutions.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
2020-11-24 07:59:14 +01:00
docs/manual: fix typo in name of a qmake-package variable Since commit 39d334faa5c1 (package/pkg-qmake: add <pkg>_SYNC_QT_HEADERS support), the qmake-package infra recognises said variable but the manual has the wrong variable name, which is missing the "_QT" part. We fix that by amending the manual to document the proper variable name. Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
2021-08-28 22:44:32 +02:00
* +LIBFOO_SYNC_QT_HEADERS+, to run syncqt.pl before qmake. Some packages
package/pkg-qmake: add <pkg>_SYNC_QT_HEADERS support Some qmake based packages need to call the syncqt.pl script before building to have a properly populated "include" directory inside the package build tree. This script is normally automatically executed by qmake when a source tree is from a git clone: buildroot purges the .git directory hence the script never runs, and we need to call it explicitly. Setting <pkg>_SYNC_QT_HEADERS = YES will force calling this script. Signed-off-by: Angelo Compagnucci <angelo@amarulasolutions.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
2020-11-24 07:59:14 +01:00
need this to have a properly populated include directory before
running the build.
Reference in New Issue Copy Permalink