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

[Daniel Pfeifer]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20170817/6fd6bfb4/attachment.html>