there's some issue related to detecting libexecinfo when openssl is installed from ports - if bundled yassl is selected, cmake picks some headers from the ports' openssl. this doesn't build, of course.

see also http://redports.org/

Problem with hack in cmake/os/FreeBSD.cmake is incorrect due to a number of reasons:
1. Uses hardcoded paths - in FreeBSD we have LOCALBASE - path where all packages in system already installed, which, by default, is /usr/local, but this could be changed. Please do not mix with PREFIX, which is where your current port/package being installed. http://www.freebsd.org/doc/en_US.ISO8859-1/books/porters-handbook/porting-prefix.html
2. Does not use detection of library (i.e. with find_library - example - here: https://github.com/fcitx/fcitx/blob/master/cmake/FindLibexecinfo.cmake )
3. Harms when ports/security/openssl installed - build fails due to wrong headers being picked up.

This should be converted to standard find-n-use scheme (take a look at oqgraph && boost detection there).

As a skeleton and to get an idea on how port may look like you can use http://svnweb.freebsd.org/ports/head/databases/mariadb55-server/ (and mariadb55-client, which is so-called slave port) which I maintain. Please note that it deliberately turns off many parts of build and install and does it in not a very sane way - using IF(FALSE). This approach is used due to no external tunables to disable that with -DWITHOUT_XXX=1.

One of patches is for fixing build on i386: http://svnweb.freebsd.org/ports/head/databases/mariadb55-server/files/patch-extra_yassl_taocrypt_src_integer.cpp?revision=309955&view=markup

Also one of the patches (http://svnweb.freebsd.org/ports/head/databases/mariadb55-server/files/patch-sql_sys_vars.cc ) is needed to fix runtime problem with setsockopt not accepting values larger than INT_MAX/kern.hz (kern.hz by default is 1000 and rarely altered, and when there is a need to alter it - this server will definitely won't be used as a database server - mainly you need to alter kern.hz for highly loaded routers).
kern.hz: Number of clock ticks per second

Original commit message:
Add a patch to lower the valid range of mysql read/write/wait timeouts.
Such timeouts are implemented via setsockopt that doesn't accept values
larger than (INT_MAX / kern.hz).

One patch (http://svnweb.freebsd.org/ports/head/databases/mariadb55-server/files/extra-patch-include_my_compare.h ) is used for tunable to raise HA_MAX_KEY_LENGTH from 1000 to 4000 - it has been default for mysql on FreeBSD for ages and I suspect that databases with this define altered are not binary compatible with vanilla ones. Am I correct?

I could build 5.5.35 from mariadb55-server port by
1. rm files/patch-cmake_os_FreeBSD.cmake
2. download mariadb-5.5.35.tar.gz in /usr/ports/distfiles
3. make PORTVERSION=5.5.35 NO_CHECKSUM=1

Alexandr Kovalenko, re. patches. let me see, if I got it right:
1. CMakeLists.txt patches are mostly about not installing something
2. jemalloc.cmake patch is not needed (we have WITH_JEMALLOC=no on FreeBSD by default, a system malloc is used)
3. cmake/os/FreeBSD.cmake patch is already applied
4. template related patches in c/cc files are — I guess — for clang compatibility?
5. mysys/default.c — my.cnf is supposed to be in /usr/local/etc/mysql?
6. scripts/CMakeLists.txt — -pthread issue, that's clear
7. scripts/mysqld_safe.sh — ok, I cannot take the patch verbatim, but I understand the issue, will fix somehow
8. sql/item_subselect.cc — eh? clang something too?
9. sql/sys_vars.cc — you've explained it already

now, mariadb55-client:
1. include/my_compare.h — you change HA_MAX_KEY_LENGTH only in the client package? isn't it weird?

Alexandr Kovalenko, and in general, what should be our goal?

I can try to incorporate as many FreeBSD patches as possible, sure, but what else?

I mean, for debian/redhat/etc we provide our own yum/apt repositories. I didn't find an equivalent for freebsd. so, we cannot provide packages with automatic updating and everything.
We can still offer packages for download, but that's far from perfect.
We can only verify that mariadb can be built from ports, but then, files in the official mariadb port can be outdated — obviously, because we also build all pushes on all hosts, so some not-released changes might break the port. Which means, I suppose, that we need to have all files (Makefile and the rest) in the mariadb source tree. It is, of course, possible, but how they'll correspond to the official freebsd port?

MariaDB port has a new maintainer

Here's what we do. The maintainer (Bernard Spil) has a repository on github with mariadb ports (https://github.com/Sp1l/ports). We will fork it on github. Then buildbot will download a new tarball to /usr/ports/distfiles, update the distinfo file, update other port files from our fork and build. If the build fails we can fix the port if necessary and submit a pull request.

It's not perfect, in a sense it's back to the old “bakery” approach. Ideally port files should be in the source repository, so that every source tarball had its own copy. But it's reasonably simple and perhaps it'll suffice.