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

Eric Wing ewmailing at gmail.com
Wed Aug 16 12:16:24 EDT 2017


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...
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.

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

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.

Thanks,
Eric


More information about the cmake-developers mailing list