| Message ID | 1421749049-1431-1-git-send-email-richard.genoud@gmail.com |
|---|---|
| State | Rejected |
| Headers | show |
Dear Richard Genoud, On Tue, 20 Jan 2015 11:17:28 +0100, Richard Genoud wrote: > If Qt is compile as a static library, there's no point compiling qwt as > a shared library, otherwise, we will have a huge qwt lib and a huge Qt > application. > > Signed-off-by: Richard Genoud <richard.genoud@gmail.com> > --- > package/qwt/qwt.mk | 6 ++++++ > 1 file changed, 6 insertions(+) > > diff --git a/package/qwt/qwt.mk b/package/qwt/qwt.mk > index a92d6b4b1540..d783314f7e40 100644 > --- a/package/qwt/qwt.mk > +++ b/package/qwt/qwt.mk > @@ -32,6 +32,12 @@ else > QWT_CONFIG += -e 's/^.*QWT_CONFIG.*QwtOpenGL.*$$/\# QWT_CONFIG += QwtOpenGL/' > endif > > +ifeq ($(BR2_PACKAGE_QT_SHARED),y) > + QWT_CONFIG += -e 's/^.*QWT_CONFIG.*QwtDll.*$$/QWT_CONFIG += QwtDll/' > +else > + QWT_CONFIG += -e 's/^.*QWT_CONFIG.*QwtDll.*$$/\# QWT_CONFIG += QwtDll/' > +endif I think we should get rid of BR2_PACKAGE_QT_SHARED completely, and use BR2_STATIC_LIBS here instead. Moreover, we're using Qwt 6.1.0, and this version is in fact compatible with both Qt >= 4.4 and Qt >= 5.0, so it should be adapted to this, and not use a qt4 specific Config.in option. Can you work on this and resend an updated version? Thanks, Thomas
2015-01-20 17:45 GMT+01:00 Thomas Petazzoni <thomas.petazzoni@free-electrons.com>: > Dear Richard Genoud, > > On Tue, 20 Jan 2015 11:17:28 +0100, Richard Genoud wrote: >> If Qt is compile as a static library, there's no point compiling qwt as >> a shared library, otherwise, we will have a huge qwt lib and a huge Qt >> application. >> >> Signed-off-by: Richard Genoud <richard.genoud@gmail.com> >> --- >> package/qwt/qwt.mk | 6 ++++++ >> 1 file changed, 6 insertions(+) >> >> diff --git a/package/qwt/qwt.mk b/package/qwt/qwt.mk >> index a92d6b4b1540..d783314f7e40 100644 >> --- a/package/qwt/qwt.mk >> +++ b/package/qwt/qwt.mk >> @@ -32,6 +32,12 @@ else >> QWT_CONFIG += -e 's/^.*QWT_CONFIG.*QwtOpenGL.*$$/\# QWT_CONFIG += QwtOpenGL/' >> endif >> >> +ifeq ($(BR2_PACKAGE_QT_SHARED),y) >> + QWT_CONFIG += -e 's/^.*QWT_CONFIG.*QwtDll.*$$/QWT_CONFIG += QwtDll/' >> +else >> + QWT_CONFIG += -e 's/^.*QWT_CONFIG.*QwtDll.*$$/\# QWT_CONFIG += QwtDll/' >> +endif > > I think we should get rid of BR2_PACKAGE_QT_SHARED completely, and use > BR2_STATIC_LIBS here instead. you mean BR2_PREFER_STATIC_LIB, right ? > Moreover, we're using Qwt 6.1.0, and this version is in fact compatible > with both Qt >= 4.4 and Qt >= 5.0, so it should be adapted to this, and > not use a qt4 specific Config.in option. Ok, I'll check that this works with both Qts. I may have misunderstood your 1st remark, but are you planning to deprecate BR2_PACKAGE_QT_SHARED ? otherwise, I could do something like: ifeq($(sort $(BR2_PREFER_STATIC_LIB) $(BR2_PACKAGE_QT_STATIC)),y) [ compile static qwt ] else [ compile shared qwt ] endif what do you think ? regards, Richard
Richard, All, On 2015-01-23 17:00 +0100, Richard Genoud spake thusly: > 2015-01-20 17:45 GMT+01:00 Thomas Petazzoni > <thomas.petazzoni@free-electrons.com>: > > Dear Richard Genoud, > > > > On Tue, 20 Jan 2015 11:17:28 +0100, Richard Genoud wrote: > >> If Qt is compile as a static library, there's no point compiling qwt as > >> a shared library, otherwise, we will have a huge qwt lib and a huge Qt > >> application. > >> > >> Signed-off-by: Richard Genoud <richard.genoud@gmail.com> > >> --- > >> package/qwt/qwt.mk | 6 ++++++ > >> 1 file changed, 6 insertions(+) > >> > >> diff --git a/package/qwt/qwt.mk b/package/qwt/qwt.mk > >> index a92d6b4b1540..d783314f7e40 100644 > >> --- a/package/qwt/qwt.mk > >> +++ b/package/qwt/qwt.mk > >> @@ -32,6 +32,12 @@ else > >> QWT_CONFIG += -e 's/^.*QWT_CONFIG.*QwtOpenGL.*$$/\# QWT_CONFIG += QwtOpenGL/' > >> endif > >> > >> +ifeq ($(BR2_PACKAGE_QT_SHARED),y) > >> + QWT_CONFIG += -e 's/^.*QWT_CONFIG.*QwtDll.*$$/QWT_CONFIG += QwtDll/' > >> +else > >> + QWT_CONFIG += -e 's/^.*QWT_CONFIG.*QwtDll.*$$/\# QWT_CONFIG += QwtDll/' > >> +endif > > > > I think we should get rid of BR2_PACKAGE_QT_SHARED completely, and use > > BR2_STATIC_LIBS here instead. > you mean BR2_PREFER_STATIC_LIB, right ? No, the option has been renamed in the tree, see: http://git.buildroot.org/buildroot/commit/?id=665e13c85e1fd216499cdd335a88a4d1c20f175f Please, use the master branch when hacking, you'll avoid surprises later! ;-) Regards, Yann E. MORIN.
2015-01-23 17:06 GMT+01:00 Yann E. MORIN <yann.morin.1998@free.fr>: > Richard, All, > > On 2015-01-23 17:00 +0100, Richard Genoud spake thusly: >> 2015-01-20 17:45 GMT+01:00 Thomas Petazzoni >> <thomas.petazzoni@free-electrons.com>: >> > Dear Richard Genoud, >> > >> > On Tue, 20 Jan 2015 11:17:28 +0100, Richard Genoud wrote: >> >> If Qt is compile as a static library, there's no point compiling qwt as >> >> a shared library, otherwise, we will have a huge qwt lib and a huge Qt >> >> application. >> >> >> >> Signed-off-by: Richard Genoud <richard.genoud@gmail.com> >> >> --- >> >> package/qwt/qwt.mk | 6 ++++++ >> >> 1 file changed, 6 insertions(+) >> >> >> >> diff --git a/package/qwt/qwt.mk b/package/qwt/qwt.mk >> >> index a92d6b4b1540..d783314f7e40 100644 >> >> --- a/package/qwt/qwt.mk >> >> +++ b/package/qwt/qwt.mk >> >> @@ -32,6 +32,12 @@ else >> >> QWT_CONFIG += -e 's/^.*QWT_CONFIG.*QwtOpenGL.*$$/\# QWT_CONFIG += QwtOpenGL/' >> >> endif >> >> >> >> +ifeq ($(BR2_PACKAGE_QT_SHARED),y) >> >> + QWT_CONFIG += -e 's/^.*QWT_CONFIG.*QwtDll.*$$/QWT_CONFIG += QwtDll/' >> >> +else >> >> + QWT_CONFIG += -e 's/^.*QWT_CONFIG.*QwtDll.*$$/\# QWT_CONFIG += QwtDll/' >> >> +endif >> > >> > I think we should get rid of BR2_PACKAGE_QT_SHARED completely, and use >> > BR2_STATIC_LIBS here instead. >> you mean BR2_PREFER_STATIC_LIB, right ? > > No, the option has been renamed in the tree, see: > http://git.buildroot.org/buildroot/commit/?id=665e13c85e1fd216499cdd335a88a4d1c20f175f > > Please, use the master branch when hacking, you'll avoid surprises > later! ;-) yep ! Thanks for the heads up ! regards, Richard.
>>>>> "Thomas" == Thomas Petazzoni <thomas.petazzoni@free-electrons.com> writes: > Dear Richard Genoud, > On Tue, 20 Jan 2015 11:17:28 +0100, Richard Genoud wrote: >> If Qt is compile as a static library, there's no point compiling qwt as >> a shared library, otherwise, we will have a huge qwt lib and a huge Qt >> application. >> >> Signed-off-by: Richard Genoud <richard.genoud@gmail.com> >> >> +ifeq ($(BR2_PACKAGE_QT_SHARED),y) >> + QWT_CONFIG += -e 's/^.*QWT_CONFIG.*QwtDll.*$$/QWT_CONFIG += QwtDll/' >> +else >> + QWT_CONFIG += -e 's/^.*QWT_CONFIG.*QwtDll.*$$/\# QWT_CONFIG += QwtDll/' >> +endif > I think we should get rid of BR2_PACKAGE_QT_SHARED completely, and use > BR2_STATIC_LIBS here instead. I agree that it would be cleaner, but the reason the explicit QT_SHARED stuff was added was afaik a lot of systems only needed Qt in a single application / that application only used a subset of the Qt functionality, so having a static libQt while everything else was shared was quite a big win in size / startup time. It does complicate LGPL compliance and I don't know if the disk space concerns are as big these days though.
On 25/01/2015 23:20, Peter Korsgaard wrote: >>>>>> "Thomas" == Thomas Petazzoni <thomas.petazzoni@free-electrons.com> writes: > > > Dear Richard Genoud, > > On Tue, 20 Jan 2015 11:17:28 +0100, Richard Genoud wrote: > >> If Qt is compile as a static library, there's no point compiling qwt as > >> a shared library, otherwise, we will have a huge qwt lib and a huge Qt > >> application. > >> > >> Signed-off-by: Richard Genoud <richard.genoud@gmail.com> >>> > >> +ifeq ($(BR2_PACKAGE_QT_SHARED),y) > >> + QWT_CONFIG += -e 's/^.*QWT_CONFIG.*QwtDll.*$$/QWT_CONFIG += QwtDll/' > >> +else > >> + QWT_CONFIG += -e 's/^.*QWT_CONFIG.*QwtDll.*$$/\# QWT_CONFIG += QwtDll/' > >> +endif > > > I think we should get rid of BR2_PACKAGE_QT_SHARED completely, and use > > BR2_STATIC_LIBS here instead. > > I agree that it would be cleaner, but the reason the explicit QT_SHARED > stuff was added was afaik a lot of systems only needed Qt in a single > application / that application only used a subset of the Qt > functionality, so having a static libQt while everything else was shared > was quite a big win in size / startup time. yes, that's exactly my case. I've got one single Qt application, and Qt is quite huge, so making it static saves a lot of space. I didn't trying to compile with BR2_STATIC_LIBS=y, but I guess that my rootfs will be much bigger. > It does complicate LGPL compliance and I don't know if the disk space > concerns are as big these days though. > Hum... I didn't think about the static vs dynamic LGPL compliance. I'll have to check that. And for disk space concern, I must admit that I haven't got much space ( 60Mio for the rootfs, and the Qt application takes 10Mio regards, Richard
>>>>> "Richard" == Richard Genoud <richard.genoud@gmail.com> writes: Hi, >> I agree that it would be cleaner, but the reason the explicit QT_SHARED >> stuff was added was afaik a lot of systems only needed Qt in a single >> application / that application only used a subset of the Qt >> functionality, so having a static libQt while everything else was shared >> was quite a big win in size / startup time. > yes, that's exactly my case. I've got one single Qt application, and Qt > is quite huge, so making it static saves a lot of space. > I didn't trying to compile with BR2_STATIC_LIBS=y, but I guess that my > rootfs will be much bigger. Indeed. I guess this is (still) quite common. >> It does complicate LGPL compliance and I don't know if the disk space >> concerns are as big these days though. >> > Hum... I didn't think about the static vs dynamic LGPL compliance. I'll > have to check that. I'm not a lawyer, but as I understand it - Because of the LGPLs relinking requirements you basically have to provide the object files of your application. > And for disk space concern, I must admit that I haven't got much space ( > 60Mio for the rootfs, and the Qt application takes 10Mio Heh, I've been involved with projects using Qt in <10MB ;)
2015-01-26 10:54 GMT+01:00 Peter Korsgaard <peter@korsgaard.com>: >>>>>> "Richard" == Richard Genoud <richard.genoud@gmail.com> writes: > > Hi, > >>> I agree that it would be cleaner, but the reason the explicit QT_SHARED > >> stuff was added was afaik a lot of systems only needed Qt in a single > >> application / that application only used a subset of the Qt > >> functionality, so having a static libQt while everything else was shared > >> was quite a big win in size / startup time. > > > yes, that's exactly my case. I've got one single Qt application, and Qt > > is quite huge, so making it static saves a lot of space. > > I didn't trying to compile with BR2_STATIC_LIBS=y, but I guess that my > > rootfs will be much bigger. > > Indeed. I guess this is (still) quite common. > > > >> It does complicate LGPL compliance and I don't know if the disk space > >> concerns are as big these days though. > >> > > Hum... I didn't think about the static vs dynamic LGPL compliance. I'll > > have to check that. > > I'm not a lawyer, but as I understand it - Because of the LGPLs > relinking requirements you basically have to provide the object files of > your application. That's what I also understood. And it makes perfect sense ! > > And for disk space concern, I must admit that I haven't got much space ( > > 60Mio for the rootfs, and the Qt application takes 10Mio > > Heh, I've been involved with projects using Qt in <10MB ;) :) Well, I guess that I may have some possible optimization to do !
Dear Richard Genoud, On Mon, 26 Jan 2015 10:34:34 +0100, Richard Genoud wrote: > > I agree that it would be cleaner, but the reason the explicit QT_SHARED > > stuff was added was afaik a lot of systems only needed Qt in a single > > application / that application only used a subset of the Qt > > functionality, so having a static libQt while everything else was shared > > was quite a big win in size / startup time. > > yes, that's exactly my case. I've got one single Qt application, and Qt > is quite huge, so making it static saves a lot of space. > I didn't trying to compile with BR2_STATIC_LIBS=y, but I guess that my > rootfs will be much bigger. Probably. Unfortunately with kconfig, we cannot easily add one option for debug symbols, static/dynamic linking to each package. It would add gazillions of options. One possibility would be to have one global string option that you could fill in with a space-separated list of packages that you want to be built statically, even if the rest of the system is built dynamically. Best regards, Thomas
2015-01-26 12:21 GMT+01:00 Thomas Petazzoni <thomas.petazzoni@free-electrons.com>: > Dear Richard Genoud, > > On Mon, 26 Jan 2015 10:34:34 +0100, Richard Genoud wrote: > >> > I agree that it would be cleaner, but the reason the explicit QT_SHARED >> > stuff was added was afaik a lot of systems only needed Qt in a single >> > application / that application only used a subset of the Qt >> > functionality, so having a static libQt while everything else was shared >> > was quite a big win in size / startup time. >> >> yes, that's exactly my case. I've got one single Qt application, and Qt >> is quite huge, so making it static saves a lot of space. >> I didn't trying to compile with BR2_STATIC_LIBS=y, but I guess that my >> rootfs will be much bigger. > > Probably. Unfortunately with kconfig, we cannot easily add one option > for debug symbols, static/dynamic linking to each package. It would add > gazillions of options. > > One possibility would be to have one global string option that you > could fill in with a space-separated list of packages that you want to > be built statically, even if the rest of the system is built > dynamically. Indeed, a generic solution like that would be great. The solution is not straight-forward though. (but as I'm not a buildroot-internals guru, I may be missing something) What I see is that the option BR2_LIST_OF_STATIC_PACKAGES="qwt qt busybox" Will define : QWT_FORCE_STATIC=y QT_FORCE_STATIC=y BUSYBOX_FORCE_STATIC=y And the BR2_STATIC_LIB=y will define pkg-name_FORCE_STATIC=y for all packages And then, in every single package file we'll have to change: s/\<BR2_STATIC_LIB\>/pkg-name_FORCE_STATIC/g but I'm really not sure this is the best way. regards, Richard.
Dear Richard Genoud, On Mon, 26 Jan 2015 18:00:48 +0100, Richard Genoud wrote: > > Probably. Unfortunately with kconfig, we cannot easily add one option > > for debug symbols, static/dynamic linking to each package. It would add > > gazillions of options. > > > > One possibility would be to have one global string option that you > > could fill in with a space-separated list of packages that you want to > > be built statically, even if the rest of the system is built > > dynamically. > Indeed, a generic solution like that would be great. > The solution is not straight-forward though. (but as I'm not a > buildroot-internals guru, I may be missing something) > What I see is that the option > BR2_LIST_OF_STATIC_PACKAGES="qwt qt busybox" > Will define : > QWT_FORCE_STATIC=y > QT_FORCE_STATIC=y > BUSYBOX_FORCE_STATIC=y > > And the BR2_STATIC_LIB=y will define pkg-name_FORCE_STATIC=y for all packages Yes, kind of. All this should be done in the generic-package infrastructure. Something like this in the inner-package function ifneq ($(filter $(1),$(call qstrip,$(BR2_LIST_OF_STATIC_PACKAGES))),) $(2)_FORCE_STATIC = YES endif ifeq ($(BR2_STATIC_LIB),y) $(2)_FORCE_STATIC = YES endif > And then, in every single package file we'll have to change: > s/\<BR2_STATIC_LIB\>/pkg-name_FORCE_STATIC/g Indeed. > but I'm really not sure this is the best way. I don't really see a better way of doing this. Best regards, Thomas
On 25/01/15 23:20, Peter Korsgaard wrote: >>>>>> "Thomas" == Thomas Petazzoni <thomas.petazzoni@free-electrons.com> writes: [snip] > > I think we should get rid of BR2_PACKAGE_QT_SHARED completely, and use > > BR2_STATIC_LIBS here instead. > > I agree that it would be cleaner, but the reason the explicit QT_SHARED > stuff was added was afaik a lot of systems only needed Qt in a single > application / that application only used a subset of the Qt > functionality, so having a static libQt while everything else was shared > was quite a big win in size / startup time. But can't you just build with BR2_SHARED_STATIC_LIBS and link your application with --static? That's what BR2_SHARED_STATIC_LIBS was meant for, right? Regards, Arnout > > It does complicate LGPL compliance and I don't know if the disk space > concerns are as big these days though. >
>>>>> "Arnout" == Arnout Vandecappelle <arnout@mind.be> writes: > On 25/01/15 23:20, Peter Korsgaard wrote: >>>>>>> "Thomas" == Thomas Petazzoni <thomas.petazzoni@free-electrons.com> writes: > [snip] >> > I think we should get rid of BR2_PACKAGE_QT_SHARED completely, and use >> > BR2_STATIC_LIBS here instead. >> >> I agree that it would be cleaner, but the reason the explicit QT_SHARED >> stuff was added was afaik a lot of systems only needed Qt in a single >> application / that application only used a subset of the Qt >> functionality, so having a static libQt while everything else was shared >> was quite a big win in size / startup time. > But can't you just build with BR2_SHARED_STATIC_LIBS and link your application > with --static? That's what BR2_SHARED_STATIC_LIBS was meant for, right? More or less, yes. It's not optimal if the application use other libraries you want to link dynamically and you need a post-build script to get rid of the .so files in the rootfs, but it is fairly close.
2015-01-27 21:55 GMT+01:00 Peter Korsgaard <peter@korsgaard.com>: >>>>>> "Arnout" == Arnout Vandecappelle <arnout@mind.be> writes: > > > On 25/01/15 23:20, Peter Korsgaard wrote: > >>>>>>> "Thomas" == Thomas Petazzoni <thomas.petazzoni@free-electrons.com> writes: > > [snip] > >> > I think we should get rid of BR2_PACKAGE_QT_SHARED completely, and use > >> > BR2_STATIC_LIBS here instead. > >> > >> I agree that it would be cleaner, but the reason the explicit QT_SHARED > >> stuff was added was afaik a lot of systems only needed Qt in a single > >> application / that application only used a subset of the Qt > >> functionality, so having a static libQt while everything else was shared > >> was quite a big win in size / startup time. > > > But can't you just build with BR2_SHARED_STATIC_LIBS and link your application > > with --static? That's what BR2_SHARED_STATIC_LIBS was meant for, right? > > More or less, yes. It's not optimal if the application use other > libraries you want to link dynamically and you need a post-build script > to get rid of the .so files in the rootfs, but it is fairly close. Indeed. As you said, the rootfs has to be cleaned in postbuild, but that should work.
diff --git a/package/qwt/qwt.mk b/package/qwt/qwt.mk index a92d6b4b1540..d783314f7e40 100644 --- a/package/qwt/qwt.mk +++ b/package/qwt/qwt.mk @@ -32,6 +32,12 @@ else QWT_CONFIG += -e 's/^.*QWT_CONFIG.*QwtOpenGL.*$$/\# QWT_CONFIG += QwtOpenGL/' endif +ifeq ($(BR2_PACKAGE_QT_SHARED),y) + QWT_CONFIG += -e 's/^.*QWT_CONFIG.*QwtDll.*$$/QWT_CONFIG += QwtDll/' +else + QWT_CONFIG += -e 's/^.*QWT_CONFIG.*QwtDll.*$$/\# QWT_CONFIG += QwtDll/' +endif + define QWT_CONFIGURE_CMDS $(SED) $(QWT_CONFIG) $(@D)/qwtconfig.pri (cd $(@D); $(TARGET_MAKE_ENV) $(QT_QMAKE))
If Qt is compile as a static library, there's no point compiling qwt as a shared library, otherwise, we will have a huge qwt lib and a huge Qt application. Signed-off-by: Richard Genoud <richard.genoud@gmail.com> --- package/qwt/qwt.mk | 6 ++++++ 1 file changed, 6 insertions(+)