From: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
To: buildroot@busybox.net
Subject: [Buildroot] [PATCH 1/2] qt5connectivity: add sdpscanner tool for Qt5Bluetooth
Date: Tue, 19 Apr 2016 00:10:20 +0200 [thread overview]
Message-ID: <20160419001020.4db2ac0a@free-electrons.com> (raw)
In-Reply-To: <5702CDE4.1080703@mind.be>
Hello,
On Mon, 4 Apr 2016 22:26:12 +0200, Arnout Vandecappelle wrote:
> That said, I wonder why we are doing all this manual copying for qt5, instead
> of just running 'make install'. AFAICS the only thing that isn't already cleaned
> up in the finalize step are the QML files, and these can easily be cleaned up as
> a finalize hook. Thomas, do you remember why you did it this way?
I had a look at this, and I know why. If you look at the staging
installation, we do just:
$(MAKE) -C $(@D) install
without passing any DESTDIR=$(STAGING_DIR) or anything like that.
The makefiles generated by qmake support a $(INSTALL_ROOT) variable
that prefixes all installation paths. However, due to how we configure
qmake, the fixed path (after $(INSTALL_ROOT)) already contains the full
path to our staging directory. From some random Qt5-generated Makefile:
-$(INSTALL_PROGRAM) ../../lib/$(TARGET) $(INSTALL_ROOT)/home/test/buildroot/output/host/usr/arm-buildroot-linux-uclibcgnueabi/sysroot/usr/lib/$(TARGET)
That's why we don't pass any DESTDIR/INSTALL_ROOT during staging
installation, and why we do the target installation manually.
So one could say that our initial qmake configuration in qt5base.mk is
broken. That's possible. But I believe that if we try to fix this (so
that the generated Makefile don't contain this hardcoded path to the
staging directory), then qmake would no longer work "automagically" as
it currently. However, it would be really interesting to have a look at
that and see if a good solution can be found. If our Qt5 folks (Julien
and Peter Seiderer) want to have a look, it'd be great.
I had a quick look at meta-qt5 in Yocto, and here is what they do:
find . -name "Makefile*" | xargs -r sed -i "s,(INSTALL_ROOT)${STAGING_DIR_TARGET},(INSTALL_ROOT),g"
so in essence, they fixup the generated Makefile after the fact so that
they don't contain the hardcoded sysroot path. If we can't find a clean
solution with qmake, maybe that's a possible solution to simplify the
target installation of all those qt5 packages.
One thing I wonder is how packages like qwt or quazip get properly
installed to the target/staging, since they do use INSTALL_ROOT. I had
a quick look at quazip, and its Makefiles are correct, they contain:
-$(INSTALL_FILE) /home/test/buildroot/output/build/quazip-0.7.2/quazip/crypt.h $(INSTALL_ROOT)/usr/include/quazip/
I'm puzzled. Some Qt5 person to chime in and look into this problem?
Best regards,
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
next prev parent reply other threads:[~2016-04-18 22:10 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-04-04 9:56 [Buildroot] [PATCH 1/2] qt5connectivity: add sdpscanner tool for Qt5Bluetooth Julien Corjon
2016-04-04 9:56 ` [Buildroot] [PATCH 2/2] qt5connectivity: add QtNfc submodule Julien Corjon
2016-04-04 20:13 ` Arnout Vandecappelle
2016-04-13 21:53 ` Thomas Petazzoni
2016-04-18 22:01 ` Thomas Petazzoni
2016-04-19 11:43 ` [Buildroot] [PATCH v2 1/2] " Julien Corjon
2016-04-19 11:43 ` [Buildroot] [PATCH v2 2/2] qt5connectivity: add bluez5_utils option for QtBluetooth submodule Julien Corjon
2016-06-03 17:52 ` Thomas Petazzoni
2016-06-03 17:51 ` [Buildroot] [PATCH v2 1/2] qt5connectivity: add QtNfc submodule Thomas Petazzoni
2016-04-04 10:02 ` [Buildroot] [PATCH 1/2] qt5connectivity: add sdpscanner tool for Qt5Bluetooth Yegor Yefremov
2016-04-04 20:26 ` Arnout Vandecappelle
2016-04-05 14:25 ` Thomas Petazzoni
2016-04-18 22:10 ` Thomas Petazzoni [this message]
2016-04-19 10:53 ` Julien CORJON
2016-04-19 11:26 ` Thomas Petazzoni
2016-04-13 21:50 ` Thomas Petazzoni
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=20160419001020.4db2ac0a@free-electrons.com \
--to=thomas.petazzoni@free-electrons.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