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
