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
