On CentOS 7 this currently has the effect that when following our build environment setup instructions from

https://mariadb.com/kb/en/library/Build_Environment_Setup_for_Linux

you'd actually end up with the build dependencies for MariaDB 5.5 being installed instead of those for current 10.x versions, as CentOS actually provides a source RPM, but still only comes with MariaDB 5.5 by default.

This is even still true whe setting up MariaDB.(org|com) yum repositories. As there's no source RPM to fetch build dependencies from in our repositories yum-builddep will still use the 5.5 source RPM from the CentOS repository

https://src.fedoraproject.org/rpms/mariadb/blob/master/f/mariadb.spec used as base for 2 pull requests as attached.

Needed as part of buildbot to generate src.rpm:

cpack -G RPM --config ./CPackSourceConfig.cmake

pull requests add Build-Depends unconditionally so a src rpm will (should at least) contain the full list of dependencies for every component of building mariadb. If this is the wrong approach, the conditionals can be used further down the cmake files to where they are accepted/fully enabled.

Overdue PR.

danblack, I'll reply here, not in github, ok? Three pull requests, one comment, don't want to copy it in three places.

Two thoughts.
1. Did you actually test your changes? I had so many issues setting CPACK_RPM variables from plugins, and you don't even use PARENT_SCOPE. E.g. this is what I end up having for tokudb:

  GET_DIRECTORY_PROPERTY(V DIRECTORY ${CMAKE_SOURCE_DIR} DEFINITION CPACK_RPM_tokudb-engine_PACKAGE_REQUIRES)

  SET(CPACK_RPM_tokudb-engine_PACKAGE_REQUIRES "${V} jemalloc" PARENT_SCOPE)

2. This seems way too manual. It'll probably be out-of-sync even before we push it. Can we come up with something less fragile?

One way of doing it would be, say, a macro (or function, whatever)

BUILD_REQUIRES(executable_or_library> <rpm build requirement entry>)

To be used like (say, in cracklib plugin)

  CHECK_LIBRARY_EXISTS(crack FascistCheckUser "" HAVE_LIBCRACK)

  BUILD_REQUIRES(crack cracklib-devel)

and in cpack_rpm.cmake or at the end of the main CMakeListst.txt there's a check that verifies that for every FIND_PROGRAM and CHECK_LIBRARY_EXISTS there is a matching BUILD_REQUIRES. Similar to how I do it at the end of plugin.cmake.

Another option would be to replace all FIND_PROGRAM and CHECK_LIBRARY_EXISTS to require a new argument, but the first option looks easier.

Ok. Thanks for the review. I like the idea of the macro. I don't remember hitting the scope issues.

Here's a new idea, even less intrusive. A patch is worth a thousand words, so the PoC:

diff --git a/CMakeLists.txt b/CMakeLists.txt

index 8d2efac89cb..ccdb17daf6f 100644

--- a/CMakeLists.txt

+++ b/CMakeLists.txt

@@ -490,3 +490,5 @@ IF(NON_DISTRIBUTABLE_WARNING)

   MESSAGE(WARNING "

 You have linked MariaDB with GPLv3 libraries!  You may not distribute the resu>

 ENDIF()

+

+INCLUDE(build_depends)

diff --git a/cmake/build_depends.cmake b/cmake/build_depends.cmake

new file mode 100644

index 00000000000..178f1087980

--- /dev/null

+++ b/cmake/build_depends.cmake

@@ -0,0 +1,22 @@

+MACRO(FIND_DEP V)

+  SET(out ${V}_DEP)

+  IF (NOT ${out})

+    EXECUTE_PROCESS(COMMAND ${ARGN} OUTPUT_VARIABLE O OUTPUT_STRIP_TRAILING_WHITESPACE)

+    SET(${out} ${O} CACHE STRING "Package that contains ${${V}}" FORCE)

+    MESSAGE(STATUS "Need ${O} for ${${V}}")

+  ENDIF()

+ENDMACRO()

+

+GET_CMAKE_PROPERTY(ALL_VARS VARIABLES)

+FOREACH (V ${ALL_VARS})

+  IF (V MATCHES "_(EXECUTABLE|LIBRARY)$" AND ${V} MATCHES "^/")

+    IF (RPM)

+    ELSEIF (DEB)

+    ELSE ()

+      # Test: Gentoo

+      FIND_DEP(${V} equery b -ne ${${V}})

+      SET(BUILD_DEPS ${BUILD_DEPS} ${${V}_PACKAGE})

+    ENDIF ()

+  ENDIF()

+ENDFOREACH()

+LIST(REMOVE_DUPLICATES BUILD_DEPS)

What needs to be done:

• remove ELSE() # test: Gentoo branch completely.
• Add rpm (rpm -qf ?) branch (no need to add deb branch, it'll only slow down the build).
• write down BUILD_DEPS into the specs file
• test it, may be "_(EXECUTABLE|LIBRARY)$" is not enough

Ok, "_(EXECUTABLE|LIBRARY)$" is certainly not enough. It won't detect boost, for example, or any other header-only library. For this one needs to analyze headers, and this is generator-dependent. For example, for Ninja it's something like

ninja -t deps|grep '^    /'|xargs rpm -qf|sort -u

source rpm builds work in bb-10.1-serg now. Left to do:

1. fix buildbot to not try to install .src.rpm in the install step
2. fix buildbot to put .src.rpm in srpm/ not in rpm/
3. fix release scripts to put the source rpm where it belongs in a yum repo
4. update documentation about source rpms for selected distributions, don't forget the jemalloc-devel-static issue

1 and 2 are done.

dbart, 3. is on you

Nice work serg. Thankyou.

3 is done.

4 is something I'll work with greenman on to make sure it updated documentation is ready for our first release with src.rpm files.

serg: Which release do you expect will be the first one with this?

For the docs, a new Building MariaDB from a src.rpm page will need to be created and this page will need to be updated:

• https://mariadb.com/kb/en/library/why-mariadb-rpms-dont-include-the-source-rpm-srpms/

There might be other existing pages that also need to be updated, but this one needs to be updated for sure so that it mentions that some Distributions now have source RPMs available (after they're actually available of course).

I'll try to merge it into the upcoming 10.3 release, but if it'll take too long to merge, then the next 10.1.