They define macros such as "check()" which causes our code to break as
we have methods with that name.

Without this change I get CMake errors due to use of ${FLTK_INCLUDE_DIR}
and references to the non-existent vncviewer target.

These are incompatible with functions such as gettext() as clang hasn't
implemented the function attribute function_arg.

It's just confusing when this is split over two directories.

This is the current upstream so let's make use of it to get the latest
in features and fixes.

This makes our builds directly compatible with most distributions
without packagers/users having to specify extra flags.

This sets up a more correct session as there are key tasks that
need to be performed by PAM. E.g. systemd will allocate cgroups
and start base services.

In order to easily handle this as a system service the mapping of
displays is now done via a configuration file.

It is present on all UNIX systems anyway, so let's simplify things.
We will need it for more proper session startup anyway.

It is the most common init system these days so it should not be
hidden in the contrib/ directory.

This also removes all old SysV files from the contrib packages.

Install some example files to make things more easily discoverable.

because it is not only platform independent
but also allows to override the build date
This helps to make tigervnc builds reproducible

See https://reproducible-builds.org/ for why this is good

Also adds UTC flag, to be independent of timezone.
Also changes JAVA_DATE format to ISO-8601 date format.

Requires cmake-2.8.11+ from 2013

These are not allowed in C++, and have been made optional in C11.
So let's just get rid of them and any issues they may cause.

Avoid that the check_c_source_compiles tests fails due to unused
variables, since Debug adds -Werror.

The compiler might default to something older, so make sure we get
the features we need.

cmake_policy() by itself raises the minimum requirement on CMake.
We want it to be optional though, so add the necessary if() around
it.

The builtin causes errors in the test, and we're also trying to
determine if it is provided by libc or not.

We don't modify the link interface directly so these warnings are
just useless noise. We could in theory use the new naming instead,
but at least CMake 2.8.12 is buggy and screws up the link when that
policy is active.

It just makes CMake error out rather than continue without NLS
support.

We need the newer versions of Windows to get access to better
thread primitives.

On some systems, the build was picking up jpeglib.h from the system
include directories, and if the system's version of libjpeg[-turbo] used
a different API/ABI version than the one specified in JPEG_LIBRARY, this
led to a "Wrong JPEG library version" error at run time.

Useful for debugging memory leaks and access violations. It is
not available on Windows though, and there is some problem compiling
ObjectiveC++ with it turned on.

Every reasonably current system support getaddrinfo() so get rid
of the legacy fallbacks.

It fails to find stdcall functions, so we need to just hard code
things based on our minimum Windows requirements.

It ignores it anyway.

That's even more generous than Microsoft themselves, and we need
such a new version for basic IPv6 support.

Assume debug builds means it's a developer working on TigerVNC
rather than a user just compiling it. At that point we should not
accept any new warnings in the code.

Need to explicitly list DSOs.

We're not doing a sufficient job of keeping this updated so list
it as an external requirement instead.

This allows us to simplify things by getting rid of some old
compatibility code. People should really be using current versions
of GnuTLS anyway to stay secure.

This means that we can remove a lot of conditionals and fallback code.

The 1.4 branch is now live, so change the version number of the
development builds.

It's much more difficult to test for this on Windows since the
headers have version guards. Just play it safe and assume it is
missing. We can remove this check when we raise the base requirements
to Vista (or newer).

Try to link as much as possible statically in an effort to produce
binaries that can be run everywhere.

GnuTLS can have different crypto backends, and it is rarely gcrypt
these days. So we should not be including that unconditionally,
and should not be pointing people at it either. Also remove the
section about Win32 binaries as those are out of date and probably
insecure. Lastly remove the section about static builds as it is
a general issue and in no way complete with just the GnuTLS portions.