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
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