As of CMake 3.24 CMAKE_COMPILER_IS_GNU(CC|CXX) are deprecated and should
be replaced with CMAKE_(C|CXX)_COMPILER_ID which were introduced with
CMake 2.6.
-DCMAKE_BUILD_TYPE=xxx sets some C compiler flags according to the build type.
-DBUILD_CONFIG was completely overwriting them in some compiler / arch
combinations and not in others. Make it consistently "append-only", not
overwrite.
Also, enforce the same set of flags for Release and RelWithDebInfo.
This reverts ff1f611a0d as it is no longer
necessary.
Avoid assert()
By default, CMAKE_BUILD_TYPE RelWithDebInfo or Release implies
-DNDEBUG, which disables the assert() macro. MariaDB is deviating
from that. Let us be explicit to use assert() only in debug builds.
bzip2/lz4/lzma/lzo/snappy compression is now provided via *services*
they're almost like normal services, but in include/providers/
and they're supposed to provide exactly the same interface
as original compression libraries (but not everything,
only enough of if for the code to compile).
the services are implemented via dummy functions that return
corresponding error values (LZMA_PROG_ERROR, LZO_E_INTERNAL_ERROR, etc).
the actual compression libraries are linked into corresponding
provider plugins. Providers are daemon plugins that when loaded
replace service pointers to point to actual compression functions.
That is, run-time dependency on compression libraries is now on plugins,
and the server doesn't need any compression libraries to run, but
will automatically support the compression when a plugin is loaded.
InnoDB and Mroonga use compression plugins now. RocksDB doesn't,
because it comes with standalone utility binaries that cannot
load plugins.
- use FIND_PACKAGE(LIBAIO) to find libaio
- Use standard CMake conventions in Find{PMEM,URING}.cmake
- Drop the LIB from LIB{PMEM,URING}_{INCLUDE_DIR,LIBRARIES}
It is cleaner, and consistent with how other packages are handled in CMake.
e.g successful FIND_PACKAGE(PMEM) now sets PMEM_FOUND, PMEM_LIBRARIES,
PMEM_INCLUDE_DIR, not LIBPMEM_{FOUND,LIBRARIES,INCLUDE_DIR}.
- Decrease the output. use FIND_PACKAGE with QUIET argument.
- for Linux packages, either liburing, or libaio is required
If liburing is installed, libaio does not need to be present .
Use FIND_PACKAGE([LIBAIO|URING] REQUIRED) if either library is required.
Updating the debian/control file will automatically update the dependencies
in all CI environments that directly read the debian/control file, such
as Salsa-CI and buildbot.mariadb.org to some degree.
(https://github.com/MariaDB/mariadb.org-tools/issues/43)
On Debian/Ubuntu releases that don't have liburing-dev available,
automatically downgrade to libaio-dev (just like libcurl4->3 is done).
This ensures the debian/control file is always up-to-date and works for
latest Debian and Ubuntu releases, while the backwards compatibility mods
are maintained in autobake-deb.sh separately, and can be dropped from there
once support for certain platforms end.
Debian/Ubuntu availability visible at:
- https://packages.debian.org/search?searchon=names&keywords=liburing-dev
- https://packages.ubuntu.com/search?searchon=names&keywords=liburing-dev
Also modify debian/rules to force a build without libaio. Use YES instead
of ON to make the flag more logical (=turning libaio check "off").
Stop running Salsa-CI for Debian Stretch-backports, as it does not have
liburing-dev available nor is the old-old Debian stable a relevant platform
for MariaDB 10.6 to test against anymore. Since the Stretch-backports build
can no longer be made, neither can the MySQL 5.7 on Bionic upgrade test be
run, as it depended on the Stretch binary.
This commit does not modify the .travis.yml file, as Travis-CI does not
have new enough Ubuntu releases available yet. Also Travis-CI.org is
practically dead now as build times have been shrunk to near zero.
The scope of this change is also Debian/Ubuntu only. No RPM or Windows or
Mac changes are included in this commit.
This commit does not update the external libmariadb or ColumnStore
CI pipelines, as those are maintained in different repositories.
Cassandra has long been non-functional, doesn't compile, etc.,
and development on it has halted. Since MariaDB Server 10.5,
the build is disabled by default.
It makes sense to remove it as it's just taking up space.
