[Maria-discuss] RPM CMake build arguments - Fedora
Hello everybody, I want to update Fedora SPECfile to the latest best practise. This time, I want to fix CMake arguments. As the time flown, we were adding more and more arguments and for many of them, I'm not sure of their correct values. Are they (the values) ON/OFF? ON/NO? ... I already - incorrectly - filed it as a JIRA issue, but it is nicely formated, so I'd recomment to read it through. https://jira.mariadb.org/browse/MDEV-14344 You can reply to both mail and JIRA, I guess, I'll check them both. -- I'll be glad for any advice on how the values should look like, because reading through the Cmake files is kinda hard and slow for me. -- Michal Schorm Associate Software Engineer Core Services - Databases Team Red Hat
Hi, Michal! On Nov 10, Michal Schorm wrote:
Hello everybody,
I want to update Fedora SPECfile to the latest best practise. This time, I want to fix CMake arguments.
As the time flown, we were adding more and more arguments and for many of them, I'm not sure of their correct values. Are they (the values) ON/OFF? ON/NO? ...
I already - incorrectly - filed it as a JIRA issue, but it is nicely formated, so I'd recomment to read it through. https://jira.mariadb.org/browse/MDEV-14344
You can reply to both mail and JIRA, I guess, I'll check them both.
I'll reply here :)
%cmake . \ -DBUILD_CONFIG=mysql_release \ -DFEATURE_SET="community" \ -DINSTALL_LAYOUT=RPM \ -DDAEMON_NAME="%{daemon_name}" \ -DDAEMON_NO_PREFIX="%{daemon_no_prefix}" \ -DLOG_LOCATION="%{logfile}" \ -DPID_FILE_DIR="%{pidfiledir}" \ -DNICE_PROJECT_NAME="MariaDB" \
you set many values that are not used anywhere in our cmakefiles. Like NICE_PROJECT_NAME or DAEMON_NO_PREFIX. Is it something that is used in some Fedora patches?
-DRPM="%{?rhel:rhel%{rhel}}%{!?rhel:fedora%{fedora}}" \
generally, -DRPM was introduced to provide a "proper RPM installation paths" and "proper RPM feature set". I'd think that most paths you specify would be correct by default (because of -DRPM).
-DCMAKE_INSTALL_PREFIX="%{_prefix}" \ -DINSTALL_SYSCONFDIR="%{_sysconfdir}" \ -DINSTALL_SYSCONF2DIR="%{_sysconfdir}/my.cnf.d" \ -DINSTALL_DOCDIR="share/doc/%{_pkgdocdirname}" \ -DINSTALL_DOCREADMEDIR="share/doc/%{_pkgdocdirname}" \ -DINSTALL_INCLUDEDIR=include/mysql \ -DINSTALL_INFODIR=share/info \ -DINSTALL_LIBDIR="%{_lib}" \ -DINSTALL_MANDIR=share/man \ -DINSTALL_MYSQLSHAREDIR=share/%{pkg_name} \ -DINSTALL_MYSQLTESTDIR=share/mysql-test \ -DINSTALL_PLUGINDIR="%{_lib}/%{pkg_name}/plugin" \ -DINSTALL_SBINDIR=libexec \ -DINSTALL_SCRIPTDIR=bin \ -DINSTALL_SQLBENCHDIR=share \ -DINSTALL_SUPPORTFILESDIR=share/%{pkg_name} \ -DMYSQL_DATADIR="%{dbdatadir}" \ -DMYSQL_UNIX_ADDR="/var/lib/mysql/mysql.sock" \ -DTMPDIR=/var/tmp \ The first part should be straightforward. I have to provide a path or some text. Easy.
Now comes the second part:
-DENABLED_LOCAL_INFILE=ON \ -DENABLE_DTRACE=ON \ -DWITH_EMBEDDED_SERVER=%{?with_embedded:ON}%{!?with_embedded:OFF} \ -DWITH_SSL=system \ -DWITH_ZLIB=system \ -DWITH_PCRE=%{?with_bundled_pcre:system}%{!?with_bundled_pcre:bundled} \
why would you want to control WITH_PCRE manually (via with_bundled_pcre)? I'd expect you to want system pcre almost always, excluding cases when it's impossible. And our CMakeLists.txt detects that automatically. Are there, really, use cases when system pcre is available, but you want to force to use a bundled one? That's the only case when this option can be used.
-DWITH_JEMALLOC=system \ -DWITH_LIBARCHIVE=ON \ -DWITH_MARIABACKUP=%{?with_backup:ON}%{!?with_backup:NO} \ -DWITH_TOKUDB=%{?with_tokudb:DYNAMIC}%{!?with_tokudb:NO} \ -DWITH_MROONGA=%{?with_mroonga:DYNAMIC}%{!?with_mroonga:NO} \ -DWITH_OQGRAPH=%{?with_oqgraph:DYNAMIC}%{!?with_oqgraph:NO} \ -DWITH_SPHINX=%{!?with_sphinx:DYNAMIC}%{?with_sphinx:NO} \
%{?with_debug: -DCMAKE_BUILD_TYPE=Debug} \ %{?_hardened_build: -DWITH_MYSQLD_LDFLAGS="-pie -Wl,-z,relro,-z,now"}
make %{?_smp_mflags} VERBOSE=1
In this part I'm not sure, which values to use at all. ON / OFF ? ON / NO ? system / ... ?
In cmake/plugin.cmake you say:
# NO - not at all # YES - static if possible, otherwise dynamic if possible, otherwise abort # AUTO - static if possible, otherwise dynamic, if possible # STATIC - static if possible, otherwise not at all # DYNAMIC - dynamic if possible, otherwise not at all
Yes, it's for plugin variables. Those that start with PLUGIN_. Here's the complete list in 10.2: PLUGIN_ARCHIVE PLUGIN_ARIA PLUGIN_AUDIT_NULL PLUGIN_AUTH_0X0100 PLUGIN_AUTH_ED25519 PLUGIN_AUTH_PAM PLUGIN_AUTH_SOCKET PLUGIN_AUTH_TEST_PLUGIN PLUGIN_BLACKHOLE PLUGIN_CLIENT_ED25519 PLUGIN_CONNECT PLUGIN_CRACKLIB_PASSWORD_CHECK PLUGIN_DAEMON_EXAMPLE PLUGIN_DEBUG_KEY_MANAGEMENT PLUGIN_DIALOG_EXAMPLES PLUGIN_EXAMPLE PLUGIN_EXAMPLE_KEY_MANAGEMENT PLUGIN_FEDERATED PLUGIN_FEDERATEDX PLUGIN_FEEDBACK PLUGIN_FILE_KEY_MANAGEMENT PLUGIN_FTEXAMPLE PLUGIN_HANDLERSOCKET PLUGIN_INNOBASE PLUGIN_LOCALES PLUGIN_METADATA_LOCK_INFO PLUGIN_MROONGA PLUGIN_OQGRAPH PLUGIN_PARTITION PLUGIN_PERFSCHEMA PLUGIN_QA_AUTH_CLIENT PLUGIN_QA_AUTH_INTERFACE PLUGIN_QA_AUTH_SERVER PLUGIN_QUERY_CACHE_INFO PLUGIN_QUERY_RESPONSE_TIME PLUGIN_ROCKSDB PLUGIN_SEMISYNC_MASTER PLUGIN_SEMISYNC_SLAVE PLUGIN_SEQUENCE PLUGIN_SERVER_AUDIT PLUGIN_SIMPLE_PASSWORD_CHECK PLUGIN_SPHINX PLUGIN_SPIDER PLUGIN_SQL_ERRLOG PLUGIN_TEST_SQL_DISCOVERY PLUGIN_TOKUDB PLUGIN_USER_VARIABLES PLUGIN_WSREP_INFO For those variables use NO/YES/AUTO/STATIC/DYNAMIC. And don't set WITH_pluginname, like WITH_MROONGA or WITH_SPHINX, they're obsolete. Here's a tip. If you run (in a configured tree, so, after `cmake .`) cmake -L you'll get a list of options. With cmake -L|grep PLUGIN_ you'll get a list as above. With cmake -LH you'll get the list of options and a help text for each, it usually includes the set of allowed values. With cmake -LAH you'll also see options marked as "advanced", that usually means they're internal and should not be set directly. Regards, Sergei Chief Architect MariaDB and security@mariadb.org
Thanks for the commands Sergei! 1) NICE_PROJECT_NAME or DAEMON_NO_PREFIX Yes, TL:DR we have some macros, that expands in the scripts we pack with MariaDB. 2) -DRPM="%{?rhel:rhel%{rhel}}%{!?rhel:fedora%{fedora}}" I'm trying to sync SPECfile in Fedora and most RH products. For such cases I have predefined paths to nearly everything. Then in f.e. software collections, it is easy to use different paths, while having SPECfiles synchronized. 3) PCRE Good question actually :) I think now it has mostly historical reasons only. I'll check, if it still makes sense. 4) cmake -L; cmake -LH; cmake LAH Yes! That's exactly what I've been looking for, wonderful! Thanks! -- Michal Schorm Associate Software Engineer Core Services - Databases Team Red Hat On Fri, Nov 10, 2017 at 11:55 PM, Sergei Golubchik <serg@mariadb.org> wrote:
Hi, Michal!
On Nov 10, Michal Schorm wrote:
Hello everybody,
I want to update Fedora SPECfile to the latest best practise. This time, I want to fix CMake arguments.
As the time flown, we were adding more and more arguments and for many of them, I'm not sure of their correct values. Are they (the values) ON/OFF? ON/NO? ...
I already - incorrectly - filed it as a JIRA issue, but it is nicely formated, so I'd recomment to read it through. https://jira.mariadb.org/browse/MDEV-14344
You can reply to both mail and JIRA, I guess, I'll check them both.
I'll reply here :)
%cmake . \ -DBUILD_CONFIG=mysql_release \ -DFEATURE_SET="community" \ -DINSTALL_LAYOUT=RPM \ -DDAEMON_NAME="%{daemon_name}" \ -DDAEMON_NO_PREFIX="%{daemon_no_prefix}" \ -DLOG_LOCATION="%{logfile}" \ -DPID_FILE_DIR="%{pidfiledir}" \ -DNICE_PROJECT_NAME="MariaDB" \
you set many values that are not used anywhere in our cmakefiles. Like NICE_PROJECT_NAME or DAEMON_NO_PREFIX. Is it something that is used in some Fedora patches?
-DRPM="%{?rhel:rhel%{rhel}}%{!?rhel:fedora%{fedora}}" \
generally, -DRPM was introduced to provide a "proper RPM installation paths" and "proper RPM feature set". I'd think that most paths you specify would be correct by default (because of -DRPM).
-DCMAKE_INSTALL_PREFIX="%{_prefix}" \ -DINSTALL_SYSCONFDIR="%{_sysconfdir}" \ -DINSTALL_SYSCONF2DIR="%{_sysconfdir}/my.cnf.d" \ -DINSTALL_DOCDIR="share/doc/%{_pkgdocdirname}" \ -DINSTALL_DOCREADMEDIR="share/doc/%{_pkgdocdirname}" \ -DINSTALL_INCLUDEDIR=include/mysql \ -DINSTALL_INFODIR=share/info \ -DINSTALL_LIBDIR="%{_lib}" \ -DINSTALL_MANDIR=share/man \ -DINSTALL_MYSQLSHAREDIR=share/%{pkg_name} \ -DINSTALL_MYSQLTESTDIR=share/mysql-test \ -DINSTALL_PLUGINDIR="%{_lib}/%{pkg_name}/plugin" \ -DINSTALL_SBINDIR=libexec \ -DINSTALL_SCRIPTDIR=bin \ -DINSTALL_SQLBENCHDIR=share \ -DINSTALL_SUPPORTFILESDIR=share/%{pkg_name} \ -DMYSQL_DATADIR="%{dbdatadir}" \ -DMYSQL_UNIX_ADDR="/var/lib/mysql/mysql.sock" \ -DTMPDIR=/var/tmp \ The first part should be straightforward. I have to provide a path or
some text. Easy.
Now comes the second part:
-DENABLED_LOCAL_INFILE=ON \ -DENABLE_DTRACE=ON \ -DWITH_EMBEDDED_SERVER=%{?with_embedded:ON}%{!?with_embedded:OFF}
\
-DWITH_SSL=system \ -DWITH_ZLIB=system \ -DWITH_PCRE=%{?with_bundled_pcre:system}%{!?with_bundled_pcre:bundled}
\
why would you want to control WITH_PCRE manually (via with_bundled_pcre)? I'd expect you to want system pcre almost always, excluding cases when it's impossible. And our CMakeLists.txt detects that automatically.
Are there, really, use cases when system pcre is available, but you want to force to use a bundled one? That's the only case when this option can be used.
-DWITH_JEMALLOC=system \ -DWITH_LIBARCHIVE=ON \ -DWITH_MARIABACKUP=%{?with_backup:ON}%{!?with_backup:NO} \ -DWITH_TOKUDB=%{?with_tokudb:DYNAMIC}%{!?with_tokudb:NO} \ -DWITH_MROONGA=%{?with_mroonga:DYNAMIC}%{!?with_mroonga:NO} \ -DWITH_OQGRAPH=%{?with_oqgraph:DYNAMIC}%{!?with_oqgraph:NO} \ -DWITH_SPHINX=%{!?with_sphinx:DYNAMIC}%{?with_sphinx:NO} \
%{?with_debug: -DCMAKE_BUILD_TYPE=Debug} \ %{?_hardened_build: -DWITH_MYSQLD_LDFLAGS="-pie -Wl,-z,relro,-z,now"}
make %{?_smp_mflags} VERBOSE=1
In this part I'm not sure, which values to use at all. ON / OFF ? ON / NO ? system / ... ?
In cmake/plugin.cmake you say:
# NO - not at all # YES - static if possible, otherwise dynamic if possible, otherwise
abort
# AUTO - static if possible, otherwise dynamic, if possible # STATIC - static if possible, otherwise not at all # DYNAMIC - dynamic if possible, otherwise not at all
Yes, it's for plugin variables. Those that start with PLUGIN_. Here's the complete list in 10.2:
PLUGIN_ARCHIVE PLUGIN_ARIA PLUGIN_AUDIT_NULL PLUGIN_AUTH_0X0100 PLUGIN_AUTH_ED25519 PLUGIN_AUTH_PAM PLUGIN_AUTH_SOCKET PLUGIN_AUTH_TEST_PLUGIN PLUGIN_BLACKHOLE PLUGIN_CLIENT_ED25519 PLUGIN_CONNECT PLUGIN_CRACKLIB_PASSWORD_CHECK PLUGIN_DAEMON_EXAMPLE PLUGIN_DEBUG_KEY_MANAGEMENT PLUGIN_DIALOG_EXAMPLES PLUGIN_EXAMPLE PLUGIN_EXAMPLE_KEY_MANAGEMENT PLUGIN_FEDERATED PLUGIN_FEDERATEDX PLUGIN_FEEDBACK PLUGIN_FILE_KEY_MANAGEMENT PLUGIN_FTEXAMPLE PLUGIN_HANDLERSOCKET PLUGIN_INNOBASE PLUGIN_LOCALES PLUGIN_METADATA_LOCK_INFO PLUGIN_MROONGA PLUGIN_OQGRAPH PLUGIN_PARTITION PLUGIN_PERFSCHEMA PLUGIN_QA_AUTH_CLIENT PLUGIN_QA_AUTH_INTERFACE PLUGIN_QA_AUTH_SERVER PLUGIN_QUERY_CACHE_INFO PLUGIN_QUERY_RESPONSE_TIME PLUGIN_ROCKSDB PLUGIN_SEMISYNC_MASTER PLUGIN_SEMISYNC_SLAVE PLUGIN_SEQUENCE PLUGIN_SERVER_AUDIT PLUGIN_SIMPLE_PASSWORD_CHECK PLUGIN_SPHINX PLUGIN_SPIDER PLUGIN_SQL_ERRLOG PLUGIN_TEST_SQL_DISCOVERY PLUGIN_TOKUDB PLUGIN_USER_VARIABLES PLUGIN_WSREP_INFO
For those variables use NO/YES/AUTO/STATIC/DYNAMIC. And don't set WITH_pluginname, like WITH_MROONGA or WITH_SPHINX, they're obsolete.
Here's a tip. If you run (in a configured tree, so, after `cmake .`)
cmake -L
you'll get a list of options. With
cmake -L|grep PLUGIN_
you'll get a list as above. With
cmake -LH
you'll get the list of options and a help text for each, it usually includes the set of allowed values. With
cmake -LAH
you'll also see options marked as "advanced", that usually means they're internal and should not be set directly.
Regards, Sergei Chief Architect MariaDB and security@mariadb.org
Hi, Michal! On Nov 13, Michal Schorm wrote:
3) PCRE Good question actually :) I think now it has mostly historical reasons only. I'll check, if it still makes sense.
To clarify. There can be four cases: 1. system PCRE is usable, WITH_PCRE=system = mariadb uses system pcre (default behaviour would be system) 2. system PCRE is usable, WITH_PCRE=bundled = mariadb uses bundled pcre (default behaviour would be system) 3. system PCRE is not usable, WITH_PCRE=system = error. doesn't build (default behaviour would be bundled) 4. system PCRE is not usable, WITH_PCRE=bundled = mariadb uses bundled pcre (default behaviour would be bundled) As you see, in cases 1 and 4 the default behavior does what you want. In the case 3 it doesn't build at all, so it's not a configuration you'll be using. The case 2 is the only possible combination where forcing WITH_PCRE would make any meaningful difference. So if the case 2 is important to you - you need to set WITH_PCRE. If you don't care about it (and generally don't want to bundle PCRE, if it can be avoided) - you don't need to set WITH_PCRE at all. Regards, Sergei Chief Architect MariaDB and security@mariadb.org
Am 10.11.2017 um 20:59 schrieb Michal Schorm:
I want to update Fedora SPECfile to the latest best practise. This time, I want to fix CMake arguments.
As the time flown, we were adding more and more arguments and for many of them, I'm not sure of their correct values. Are they (the values) ON/OFF? ON/NO? ...
it's a terrible mess of TRUE/FALSE, YES/NO, ON/OFF, WITH/WITHOUT
participants (3)
-
Michal Schorm -
Reindl Harald -
Sergei Golubchik