MariaDB released an update for 10.0 a couple of days ago. This should be made available to all users. Time to backport the improvements made for 10.1 to the 10.0 port as well!

Fixing the build problems with 10.1 yesterday was a complete disaster. Fixing one thing would break something else. Time to try something easier.

This should be a straight-forward 10.0 update as 10.1 is released I'm not expecting anything other than bug fixing for 10.0. But I'm sure I'll find ways to break things!

Update to 10.0.24

All seems well with the updated port. Just bumped the PORTVERSION in the Makefile and regenerated distinfo and all was well.

Building client

Obviously the jemalloc cmake patch is no longer required. Sending patches upstream obviously works!

After removal of an extraneous -DWITH_JEMALLOC=system from the CMAKE_FLAGS. check-plist is OK as well. portlint shows no difference from the previous version.

Back-porting changes

When creating the 10.1 port I made a lot of improvements to the port. These should all be applied to the 10.0 port as well.

FreeBSD ports should not use bundled libs when there are shared libraries available in base or ports.

OpenSSL

Following the above statement on bundled libs, the OpenSSL options have got to go! Always link the OpenSSL libs from ports or base, depending on the user's choice

 OPTIONS_DEFINE=        FASTMTX
-OPTIONS_RADIO=         SSL
-OPTIONS_RADIO_SSL=     BUNDLED_SSL OPENSSL WITHOUT_SSL
-OPTIONS_DEFAULT+=      OPENSSL
 NO_OPTIONS_SORT=       yes
...
-BUNDLED_SSL_CMAKE_ON=  -DWITH_SSL=bundled
 FASTMTX_CMAKE_ON=      -DWITH_FAST_MUTEXES=1
-OPENSSL_CMAKE_ON=      -DWITH_SSL=yes
-OPENSSL_USE=   OPENSSL=yes
-WITHOUT_SSL_CMAKE_ON=  -DWITH_SSL=no
+USE_OPENSSL=           yes
...
+               -DWITH_SSL=${OPENSSBASE} \

That's now implemented as it is on 10.1

Bundled libraries

We have lzma libraries in base, and snappy is available from archivers/snappy. Luckily the patch created for 10.1 can be used here as well. Easy fix

Storage engines options

With 10.1 I have re-worked the engines into an options group and added engines that were previously not optional (Sphinx, Spider)

OPTIONS_GROUP=          ENGINES
OPTIONS_GROUP_ENGINES=  INNOBASE MROONGA OQGRAPH SPHINX SPIDER TOKUDB

ENGINES_DESC=   Optional MariaDB storage engines
INNOBASE_DESC=  Build InnoDB engine next to XtraDB
MAXKEY_DESC=    Change max key length from 1000 to 4000
MROONGA_DESC=   Mroonga Full Text Search engine
OQGRAPH_DESC=   Open Query Graph Computation engine (Requires GCC)
SPHINX_DESC=    SphinxSE engine
SPIDER_DESC=    Partitioning and XA-transactions engine
TOKUDB_DESC=    Fractal tree index tree data structure engine

The new part is that I've now made adding engines trivial, using the options framework

.for ENGINE in ${OPTIONS_GROUP_ENGINES}
${ENGINE}_CMAKE_OFF=   -DWITHOUT_${ENGINE}=1
.endfor

Beware that this changes the INNODB option to INNOBASE. The pkg-plist was updated accordingly.

GCC-isms

Ran into a build-failure with the connect engine. clang fails if you pass a string literal where it expects a specific type. Reported the bug with a fix.

Had to implement the patch from 10.1 for TokuDB.

Testing all engines

Some of the engines have specific requirements with regards to building. TokuDB is not supported on 32-bit platforms, OQGraph will not build with clang so we must force gcc.

Altogether this makes for a large number of possible options. Testing takes quite some time to build on my system.

Build without additional storage engines was OK. Build with all storage engines ''except'' OQGraph was OK (after adding some patches from 10.1) Build with OQGraph surfaced a nice typo OQGR''P''AH but builds after fixing

Last test for today, ALL engines enabled. Fingers crossed!