[cmake-developers] Future of ccmake and cmake-gui

[David Cole]

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 <daniel at pfeifer-mail.de> wrote:
> On Wed, Aug 16, 2017 at 6:16 PM, Eric Wing <ewmailing at gmail.com> wrote:
>>
>> On 8/15/17, Daniel Pfeifer <daniel at 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