This is great to see CMake continuing to evolve like this! What's next, a web page CMake UI connected to cmake server instances on multiple platforms? ;-)
On Wed, Aug 16, 2017 at 6:05 PM, Daniel Pfeifer <dan...@pfeifer-mail.de> wrote: > On Wed, Aug 16, 2017 at 6:16 PM, Eric Wing <ewmail...@gmail.com> wrote: >> >> On 8/15/17, Daniel Pfeifer <dan...@pfeifer-mail.de> wrote: >> > Hi, >> > >> > With !977 merged, it is possible to base ccmake and cmake-gui on top of >> > the >> > cmake server. >> > For demonstration, I copied the contents of the Source/CursesDialog >> > directory and added a proxy implementation of the classes `cmake` and >> > `cmState`. The result is 100% compatible with `ccmake`. The same would >> > be >> > possible with cmake-gui. >> > >> > Shall we proceed in this direction? >> > >> > To make the server available everywhere, we should backport the code >> > from >> > C++14 to C++11. I think this is limited to replacing `std::make_shared`. >> > >> > For cmake-gui, the proxies could use Qt functionality (QProcess, >> > QJsonDocument, etc.). As a result, cmake-gui would not have any build >> > dependencies apart from Qt. >> > >> > It might be worth considering to move ccmake and cmake-gui to their own >> > repositories. >> > >> > Cheers, Daniel >> > >> >> If this is a new rewrite... > > > It is not. Both ccmake and cmake-gui use the use the `cmake` class as a > facade to the cmakelib. > In my prototype I re-implemented the `cmake` class as a client to the > cmake-server using json-cpp and libuv. > This allows separating ccmake and cmake-gui from the cmakelib without > further changes to the rest of the code. > > The same client implementation might be used for ccmake and cmake-gui, but > cmake-gui might as well use Qt facilities instead. > >> 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). And the >> binary sizes are large. (I do ship CMake to my users and its size with >> the GUI is non-trivial.) >> >> CMake's actual GUI isn't that complex. Have you considered something >> lighter-weight? >> >> As one alternative, there is IUP: >> http://webserver2.tecgraf.puc-rio.br/iup/ >> (it's from the same university that created Lua...in fact I think one >> of the original authors of the white paper/project went on to become >> one of the Lua authors.) >> >> IUP differs from Qt in that is is focused on wrapping native GUI >> widgets (in constrast to Qt which creates its own non-native widgets). >> Hence, the library is really small since it only depends on each >> platform's native libraries. The core library is about 1MB. I just >> ported (rewrote) a simple Qt based app to IUP. The Qt version was >> almost 40MB. The IUP RAM usage is also many times smaller. >> >> It has native backends for Windows, GTK2, GTK3, Motif, Haiku. Because >> it historically didn't have a Mac OS X backend, most people overlooked >> it. However...I've been implementing a native Mac OS X backend. It's >> not finished, but there is a lot implemented and I'm actually shipping >> a simple app with it this week. Since CMake's GUI usage is also pretty >> simple, I *think* there might already be enough implemented to do the >> CMake-GUI...or it's close enough that I probably could finish those >> needed features. >> >> Also, I implemented a CMake build system for IUP. >> >> IUP is MIT licensed. > > > Sounds interesting. > >> Now IUP only does GUI (which is another reason it stays small), so you >> will need to fill in the JSON and Process requirements. But there are >> tons of JSON libraries. Off the top of my head, cJSON is a really >> fast, tiny, and simple to use JSON library. It's a single C file and >> header, so you can drop it right in the project. (Also MIT). It also >> has a CMake build system if you really want it. >> >> >> >> And a cross-platform create process...those I've seen everywhere and >> I've actually written my own too. I think Apache Runtime is only >> measured in hundreds of kilobytes even with all the stuff you don't >> need. >> A quick Google search turned up this one C++ (MIT) >> https://github.com/eidheim/tiny-process-library > > > That would not be necessary. A cache editor build on IUP could use the same > cmake client implementation as ccmake. > >> So IUP + some JSON + some Process should be around 1MB-2MB. This is in >> contrast to the Qt frameworks I have right now in my CMake bundle for >> Mac. >> >> >> Anyway, I know this is going to be outside peoples' comfort-zone which >> is why I'm not going to push hard on it. But in general, I would like >> something smaller, easier to build, and lighter on system resources >> (and real native GUIs generally provide a better user experience). So >> I'm hoping to at least get you thinking about that irrespective of any >> particular framework. And if there is interest in IUP, I'm happy to >> discuss more or help. > > > The good thing is that a new CMake GUI does not need to link against > cmakelib. Hence, it does not need to live in CMake's repository. You may > copy the cmake client implementation from > https://github.com/purpleKarrot/nccmake and build a CMake GUI using IUP. > > Cheers, Daniel > > -- > > 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 -- 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
