From: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
To: buildroot@busybox.net
Subject: [Buildroot] Making the Qt5 packaging compatible with per-package folder
Date: Fri, 16 Nov 2018 17:18:45 +0100 [thread overview]
Message-ID: <20181116171845.4bc2a936@windsurf> (raw)
Peter, Ga?l,
I don't know if you have followed the discussion, but I recently sent a
new iteration of the per-package folder series [1], which allows to
support top-level parallel build.
One issue is that the Qt5 packaging as done today in Buildroot is not
compatible with per-package folders.
If you remember well, the installation of each Qt5 module works like
this:
- Staging installation
Just "make install". No DESTDIR or INSTALL_ROOT is passed, because
the installation path is hardcoded in qmake itself. "make install"
will install stuff to both $(HOST_DIR) and $(STAGING_DIR).
- Target installation
We manually copy the shared libraries, QML files, fonts, and other
stuff. This is already annoying to maintain today, because we
sometimes forget to install something that is important, we need to
handle the LTS/latest Qt5 version difference, etc. It would be a lot
less maintenance if we could use "make install" also for the target
installation.
Even if the current packaging is not ideal, it worked fine. But it
breaks badly with per-package folders. As explained above, the paths in
qmake are hardcoded. So when you do "make install" in qt5location for
example, it ends up being installed in the per-package folder of
qt5base (both HOST_DIR and STAGING_DIR), as it's the qt5base
HOST_DIR/STAGING_DIR that are hardcoded inside the qmake binary.
I tried to fix this issue, but for the moment, I haven't found a
solution. I first tried to use the -extprefix ./configure option, but
it didn't behave as we needed. Then I tried to do some manual
replacement in the Qt5 Makefiles after they have been generated (like
OpenEmbedded is doing), but they unfortunately get re-generated because
we tweak the .prl files from Qt5, and the Qt5 Makefiles regenerates the
Mkaefiles if they are older than the .prl files.
The current status of my experiment is visible at
https://git.bootlin.com/users/thomas-petazzoni/buildroot/commit/?h=ppsh-qt5&id=676d26ab1ca3d8f8ee5788dbc06f4e0703188bf1,
with a very long commit that explains the problem, and what was tried
so far. At this point, I am considering cheating on the date of
the .prl file to avoid the Makefiles from being re-generated, but this
is really a hack on top of what is already a hack.
Do you have some other ideas to solve this ? Can we fix qmake to do the
right thing ?
Thanks a lot for your help,
Thomas
[1] http://patchwork.ozlabs.org/project/buildroot/list/?series=75909
--
Thomas Petazzoni, CTO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
next reply other threads:[~2018-11-16 16:18 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-11-16 16:18 Thomas Petazzoni [this message]
2018-12-03 16:22 ` [Buildroot] Making the Qt5 packaging compatible with per-package folder Thomas Petazzoni
2018-12-05 22:36 ` Peter Seiderer
2018-12-07 20:50 ` Peter Seiderer
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20181116171845.4bc2a936@windsurf \
--to=thomas.petazzoni@bootlin.com \
--cc=buildroot@busybox.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox