Network and Concurrent module release, planned feature set reached

With this official release, LeanQt has reached the feature set planned to date.

The QtNetwork and QtConcurrent modules are fully migrated to LeanQt with new configuration options. The basic configuration only builds QUdpSocket, QTcpSocket, QTcpServer, QDnsLookup and QNetworkProxy; in contrast to original Qt also QFtp is available in the public API. Like before SSL is a separate option; only dynamic loading of the OpenSSL shared library is supported (I will look for an alternative implementation based on mbedTLS). Local sockets, the QNetworkAccessManager with helper classes, as well as bearing and authentication are options that can be enabled via parameters; see the comments for the HAVE_* parameters in https://github.com/rochus-keller/LeanQt/blob/main/BUSY. The code has been modified to reduce mutual dependencies so most options can be individually switched on or off.

With this release LeanQt is ready for non-GUI network applications (like webservers or clients). There are bearer plugins in a separate directory of the original Qt source tree though, which I've never used for the last twenty years, and thus didn't migrate; if you urgently need some of these, please post an issue.

The core module has the new HAVE_ZLIB option to enable qCompress and qUncompress. The net module has been modified so it works with or without ZLIB. In contrast to original Qt ZLIB is an implementation detail of the core module and not directly used by the net module anymore.

This release of LeanQt also uses the most recent features of the BUSY build system; see below for an example.

Copy Example

Instances of the BUSY Copy class can be used at the top level of the build (and also on other levels of course) to both initiate the build for all dependent parts and to copy the resulting libraries or executables to a dedicated directory.

Here is an excerpt of the LeanQt root BUSY file which builds all libraries and examples according to the selected options:

submod examples

let build_examples ! : Copy {
	.use_deps += `executable
	.deps += examples.hello
	if HAVE_OBJECT {
		.deps += examples.objects
	}
	if HAVE_THREADS {
		.deps += examples.threads
	}
	if HAVE_PROCESS {
		.deps += examples.process
	}
	if HAVE_NET_MINIMUM && HAVE_CMDLINE {
		.deps += examples.dnslookup
	}
	if HAVE_CONCURRENT {
		.deps += examples.concurrent
	}
	if HAVE_NETACCESS && HAVE_FILEIO {
		.deps += examples.download
	}
	.outputs += ./{{source_file_part}}
}

Due to the ! behind the instance name build_examples is automatically selected by BUSY to be built by default (see here for more information how to select build targets and set options via BUSY command line).

The code of the executables lives in the examples subdirectory which is also a BUSY module. Here is an excerpt of the examples BUSY file which builds the dnslookup executable:

let dnslookup_moc : Moc {
	.sources += ./dnslookup.h
}

let dnslookup* : Executable {
	.sources += ./dnslookup.cpp
	.deps += [ ^libqtcore ^libqtnetwork dnslookup_moc ]
	.configs += [ ^core_client_config ^net_client_config ]
} 

The example is only built if HAVE_NET_MINIMUM && HAVE_CMDLINE is true, and if so, it first takes care that the core and net libraries are built and moc is run before compiling dnslookup.cpp and linking. The resulting dnslookup executable is copied to the BUSY root build directory.