CMake: add tigervnc library

[KangLin]

Add tigervnc development library.

Usage:

• Build：

l@l:/data/tigervnc1$ mkdir build
l@l:/data/tigervnc1$ cd build
l@l:/data/tigervnc1/build$ cmake .. -DCMAKE_INSTALL_PREFIX=install
l@l:/data/tigervnc1/build$ cmake --build .

• Install

  • Only install tigervnc development library

    l@l:/data/tigervnc1/build$ cmake --install . --component Development 
    

    l@l:/data/tigervnc1/build$ ls install
    include  lib
    

  • Only install application

    l@l:/data/tigervnc1/build$ cmake --install . --component Runtime
    

    l@l:/data/tigervnc1/build$ ls install
    bin  etc  lib  libexec  sbin  share
    

  • Install all

    l@l:/data/tigervnc1/build$ cmake --install . 
    

    l@l:/data/tigervnc1/build$ ls install
    bin  etc  include  lib  libexec  sbin  share
    

[KangLin]

Core, RDR, RFB, and Network are used to generate object libraries, and then combined into a static library tigervnc.
The application link tigervnc.

[CendioOssman]

I'm afraid we are not at a point where we could promise any kind of API stability. As such, we don't want to package any library for others to use.

It's also not something we are currently working towards. C++ makes writing libraries difficult because the ABI is so fragile. I'm not sure what that design would look like.

[KangLin]

@CendioOssman

I'm afraid we are not at a point where we could promise any kind of API stability. As such, we don't want to package any library for others to use.

Of course, it is unstable at the moment. However, with everyone's efforts, it will become stable.

It's also not something we are currently working towards.

What are working towards？

C++ makes writing libraries difficult because the ABI is so fragile. I'm not sure what that design would look like.

It turns out that the ABI written in c++ is strong and easy, e.g. Qt.
Now the framework is a good library structure. It's just that I didn't export the binary library.
Providing libraries can no longer remake the wheel for VNC. At the same time, it also attracts others to maintain.

I strongly recommend providing libraries!!!
I will help maintain.

[KangLin]

@CendioOssman

The PR only provides an API and does not involve ABI. If ABI is to be provided, a large number of modifications are required. It is mainly an export interface for dynamic libraries. I'll help modify if you want.

Currently being refactored. So offering an API from now on is the best opportunity.

The next version is v2.0.0.
Please see Semantic Versioning

[CendioOssman]

What are working towards？

This project is currently focused on providing a good multi-platform client, and a Unix server. Being a library for others to use has not been a goal.

C++ makes writing libraries difficult because the ABI is so fragile. I'm not sure what that design would look like.

It turns out that the ABI written in c++ is strong and easy, e.g. Qt. Now the framework is a good library structure. It's just that I didn't export the binary library. Providing libraries can no longer remake the wheel for VNC. At the same time, it also attracts others to maintain.

I strongly recommend providing libraries!!! I will help maintain.

That's a good start. But I'm doubtful we'll get too much uptake from others. Things like neatvnc and libvncserver already exist, and I don't see any signs there is a pressing need for another player.

If there was little cost, then we could always try. But freezing the API is a big undertaking. Especially when it wasn't designed for that to begin with. It's not something we want to spend our limited development resources on.

If you would like to make progress towards a library, I suggest you start with incremental suggestions on more minimal and stable interfaces. We don't want to export everything as the library interface.

[KangLin]

@CendioOssman

What are working towards？

This project is currently focused on providing a good multi-platform client, and a Unix server. Being a library for others to use has not been a goal.

We have similar goals. My project RabbitRemoteControl
Provide a good multi-platform client and server without a public IP over the Internet.
See: KangLin/RabbitRemoteControl#39

That's a good start. But I'm doubtful we'll get too much uptake from others. Things like neatvnc and libvncserver already exist, and I don't see any signs there is a pressing need for another player.

These are C language libraries. where libvncserver is in the stopped state. Their program structure doesn't meet my needs.
I am not find the C++ libraries that are maintained on the whole network.

If there was little cost, then we could always try. But freezing the API is a big undertaking. Especially when it wasn't designed for that to begin with. It's not something we want to spend our limited development resources on.

Although your initial target is not a library, but this project inherits the good programming habits of RealVNC. Maintain good API, multi-platform compatibility.
I see that you can refactor core, so you have good programming habits. You've actually done the API work, it's just not exported as a library.
Export as a static library and don't require too much extra work. Only this PR can complete.
Currently four static libraries are being generated. However, consider that it may conflict with other libraries (e.g. RealVNC). So, I'm going to synthesize them into a static library tigervnc in this PR.
I think your current API is well maintained, so I exported all the existing header files. It is harmless to the project.
Of course, there are improvements to these APIs (e.g. Rect, etc.), but that's not the purpose of this PR. I will submit a PR for the future.
Currently, only CMake-related development has been produced. If you accept this PR, pkg-config will be added later.

If you would like to make progress towards a library, I suggest you start with incremental suggestions on more minimal and stable interfaces. We don't want to export everything as the library interface.

Yes, I will maintain it according to this principle.