> For example, I've seen way too many projects screw up with Brew because they fail to ship a binary that can work on a clean user system who is not going to install Brew.
I must be lucky then, because just using macdeployqt copies all the dependencies for me and updates all the install paths correctly whether I use Qt's own build or brew's. > It pulls a new version of gcc instead of using Xcode/clang on your system and builds an entire dependency chain based on GNU tools. this is false. brew uses xcode & clang on your system. > Similar problem for Windows...Visual Studio is the requirement. I don't know if you are talking about Chocolatey or Qt but neither require Visual Studio on windows. Qt even comes with MinGW if you wish. > And Mac doesn't have configure/autotools by defaul. but... "configure" has nothing to do with autotools. It's just a shell script (which is sometimes generated *from* autotools; this is not the case with Qt AFAIK). > and I never figured why Qt's RAM consumption footprint is so high...based on all the DLL binary code it has to load, or something more intrinsic to its implementation. science can help us here :p two tools are very nice for this : * bloaty mcbloatface for binary bloat for file in /usr/lib/libQt5*.so ; do (echo $file; bloaty $file| grep -A3 'text') ; done tells us stuff like /usr/lib/libQt5Core.so 55.4% 2.75Mi .text 2.75Mi 55.5% 23.5% 1.16Mi .rodata 1.16Mi 23.5% 7.3% 372Ki .eh_frame 372Ki 7.4% 4.1% 210Ki .dynstr 210Ki 4.2% /usr/lib/libQt5Gui.so 70.0% 3.82Mi .text 3.82Mi 70.2% 7.8% 438Ki .eh_frame 438Ki 7.9% 6.1% 342Ki .dynstr 342Ki 6.1% 5.1% 286Ki .rodata 286Ki 5.1% A bit surprising to see .eh_frame; I thought Qt was compiled with -fno-exceptions but maybe that's just my distro. Quite a bunch of .rodata in Qt5Core too, I wonder why. Further examination through readelf -x .rodata /usr/lib/libQt5Core.so | less seems to show up a lot of locale-specific calendar text & such, e.g. names of the months in twenty languages, currencies, time zones, etc * And then, runtime examination: for this I tried making a minimal gui program: #include <QApplication> #include <QMainWindow> int main(int argc, char**argv) { QApplication app(argc, argv); QMainWindow w; w.show(); return app.exec(); } compiled with g++ -DQT_NO_DEBUG -fPIC -I/usr/include/qt/ -I/usr/include/qt/QtCore -I/usr/include/qt/QtWidgets -I/usr/include/qt/QtGui main.cpp -lQt5Core -lQt5Widgets and then use the wonderful Heaptrack (https://github.com/KDE/heaptrack) : heaptrack ./a.out which then greets us with http://imgur.com/a/eYjaL As you can see, "peak heap memory consumption" is at a bit less than 400 *kilobytes*. So the Qt memory usage that you see is clearly due only to binary bloat. And indeed (sorry for shitty bash skills): $ ldd a.out | cut -d '=' -f1 | awk '{print "/usr/lib/" $1;}' | xargs readlink | awk '{print "/usr/lib/" $1;}' | xargs du -csh | sort -h 16K /usr/lib/libdl-2.25.so 16K /usr/lib/libXau.so.6.0.0 24K /usr/lib/libXdmcp.so.6.0.0 32K /usr/lib/librt-2.25.so 64K /usr/lib/libdouble-conversion.so.1.0.0 68K /usr/lib/libbz2.so.1.0.6 72K /usr/lib/libGLX.so.0.0.0 72K /usr/lib/libXext.so.6.4.0 80K /usr/lib/liblz4.so.1.7.5 84K /usr/lib/libgpg-error.so.0.22.0 92K /usr/lib/libz.so.1.2.11 144K /usr/lib/libpthread-2.25.so 152K /usr/lib/liblzma.so.5.2.3 164K /usr/lib/libxcb.so.1.1.0 176K /usr/lib/libgraphite2.so.3.0.1 216K /usr/lib/libpng16.so.16.31.0 444K /usr/lib/libpcre2-16.so.0.5.0 460K /usr/lib/libpcre.so.1.2.9 536K /usr/lib/libsystemd.so.0.19.0 548K /usr/lib/libharfbuzz.so.0.10400.5 552K /usr/lib/libGL.so.1.0.0 600K /usr/lib/libGLdispatch.so.0.0.0 796K /usr/lib/libfreetype.so.6.14.0 1,1M /usr/lib/libglib-2.0.so.0.5200.3 1,1M /usr/lib/libm-2.25.so 1,2M /usr/lib/libgcrypt.so.20.2.0 1,3M /usr/lib/libX11.so.6.3.0 1,7M /usr/lib/libicuuc.so.59.1 1,9M /usr/lib/libc-2.25.so 2,5M /usr/lib/libicui18n.so.59.1 5,0M /usr/lib/libQt5Core.so.5.9.1 5,5M /usr/lib/libQt5Gui.so.5.9.1 6,4M /usr/lib/libQt5Widgets.so.5.9.1 12M /usr/lib/libstdc++.so.6.0.24 26M /usr/lib/libicudata.so.59.1 69M total So there's 17 megabytes of Qt in here; hopefully the rest would already be loaded by your system. Best, Jean-Michaël On Thu, Aug 17, 2017 at 3:34 AM, Eric Wing <ewmail...@gmail.com> wrote: > On 8/16/17, Jean-Michaël Celerier <jeanmichael.celer...@gmail.com> wrote: > > @Eric Wing > >> I am not making a strong push for this, but I want to bring it up to > > at least get people thinking about this... I am disturbed by the size > > and complexity of Qt. My past experiences have not been good and I > > find it a massive chore to get an environment setup (especially on Mac > > and Windows...and building Qt on Raspberry Pi is a nightmare). > > > > Really ? On mac it's just brew install qt. On windows choco install > qt-sdk > > (and it even comes with mingw so that you don't necessarily have to > install > > visual studio). > > On Raspberry sudo apt-get install qtbase5-dev. > > > > So 3rd party package systems are banned for me. They cause too many > dependency problems themselves. For example, I've seen way too many > projects screw up with Brew because they fail to ship a binary that > can work on a clean user system who is not going to install Brew. > Also, it causes needless redundancy and changes the toolset if I > recall. It pulls a new version of gcc instead of using Xcode/clang on > your system and builds an entire dependency chain based on GNU tools. > Similar problem for Windows...Visual Studio is the requirement. > > As for Pi, I think the problem I had was the Qt available in the repo > at the time was too old for me. (Typical Debian long release cycle > problem.) > > But I still consider it a problem if these things are too hard to > build because (especially for me) there is always a new platform that > needs to be ported to. > > > > Building qt itself is a matter of doing (cue errors from typing in a mail > > without checking) > > > > git clone https://github.com/qt/qt5 > > cd qt5 ; git submodule update --init qtbase ... # whatever submodules you > > need > > ./configure -open-source -confirm-license -nomake tests -nomake examples > > -prefix /opt/my-qt > > make -j8 && make install > > > > My last experience was that there were critical bugs in the Qt Mac > release at the time (and this was the official binary release). And > Mac doesn't have configure/autotools by defaul. Again...no brew for > various reasons like above. > > > > > Maybe consider a LTCG build (-ltcg) if this really matters ? This way I > can > > get a moderately complex GUI app that uses gui, widgets, network, qml, > > etc... > > under ten megabytes, so something like cmake-gui should be way smaller... > > (this also removes any problem related to DLLs). > > I wouldn't be able to say. And I never figured why Qt's RAM > consumption footprint is so high...based on all the DLL binary code it > has to load, or something more intrinsic to its implementation. > > > -Eric >
-- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers