Actually Timofei,
I'll draw the CoC to you, since you have claimed I used a work in which
I did NOT in fact use, by actually using that word yourself.
Oh, and I have been on this list long enough to know who has the right
to direct me to such reminders should I infact use such language, and
you, a "johnny come lately", are not one.
i stopped reading at that, because its quite obvious you're out to make
problems for anyone woh disagrees with you, save your breath, and after
you apologise to the list for using offensive language, ensure you dont
mail me directly again.
On 16/05/2026 05:17, Timofei Zhakov wrote:
On Thu, May 14, 2026 at 12:49 PM Noel Butler <[email protected]>
wrote:
On 14/05/2026 14:54, Branko Čibej wrote:
Its convoluted. Its messy.
Lets take sql as a horrid example (but its similar with the only other
forced cmake requirement that we use being clamav), what used to
configured and built with autotools could be done as such, clear
simple EASY for even the most junior and senior administrator alike to
config from memory -
./configure --prefix=/usr --localstatedir=/usr/mysql/data
--datadir=/var/lib/mysql
done...
BUT cmake to do same thing requires this crap (supplied my mariadb
team member to mimic our build requirements)
cmake -DCMAKE_C_FLAGS="-O2 -fPIC" -DCMAKE_CXX_FLAGS="-O2 -fPIC"
-DFEATURE_SET="community" -DCMAKE_INSTALL_PREFIX=/usr -D
INSTALL_LIBDIR="lib64" -DINSTALL_SBINDIR=libexec
-DINSTALL_INCLUDEDIR=include/mysql -DINSTALL_MYSQLSHAREDIR=share/mysql
-DINSTALL_SQLBENCHDIR="" -DINSTALL_MYSQLTESTDIR=mysql-test
-DINSTALL_MANDIR=man -DINSTALL_PLUGINDIR="lib64/mysql/plugin"
-DINSTALL_SCRIPTDIR=bin -DINSTALL_SUPPORTFILESDIR=share/mysql
-DINSTALL_MYSQLDATADIR="/var/lib/mysql" -DMYSQL_DATADIR="
/var/lib/mysql" -DMYSQL_UNIX_ADDR="/var/run/mysql/mysql.sock"
-DWITH_EXTRA_CHARSETS=complex -DWITH_INNOBASE_STORAGE_ENGI
NE=1 -DENABLED_LOCAL_INFILE=ON -DWITH_LIBARCHIVE=ON -DWITH_READLINE=ON
-DWITH_JEMALLOC=system -DWITH_ZLIB=system -DWITH_
EXTERNAL_ZLIB=ON -DWITH_SSL=system -DCONC_WITH_SSL=ON
-DUSE_ARIA_FOR_TMP_TABLES=ON -DAWS_SDK_EXTERNAL_PROJECT=OFF
Then running make...
THEN to upgrade each version you have to screw around with garbage
like
rm $(</root/install_manifest-MARIADB.txt)
make install
cp install_manifest.txt /root/install_manifest-MARIADB.txt
(Sure you don't need to cp and use /root/install_manifest but if
someone clears out the source code you will be left with pieces of
older versions, so you copy it, and lets not forget that file is not
created until the program is built and installed, its not something
you can pluck out of a tarball
all because there is no make uninstall....
And clamav as mentioned earlier, before it was just
./configure --prefix=
NOW it too requires all the manual rm BS as maria/mysql above, but at
least its CMAKE line is much shorter..
cmake .. -D CMAKE_INSTALL_PREFIX=/usr/local -D
CMAKE_INSTALL_LIBDIR=lib64 -D APP_CONFIG_DIRECTORY=/etc/clamav -D
DATABASE_DIRECTORY=/var/lib/clamav
you try remembering all that crap when you need to off the top of your
head, and using a cheatsheet (like we obviously are doing) is not an
excuse.
I reckon the same morons who are involved in systemd are involved in
cmake, 12 lines to do with what cron does in 1
/that completes this years rant
You just described two horribly broken CMake build systems. In the two
cases you mentioned, the fault lies with the authors, not with CMake.
:)
yes, its a proble with cmake (see my end) and if the mariadb team
can't get it right as you claim, then its more of a reason to avoid
the garbage.
Well, except in the sense that CMake has zero, nil, zilch, none
whatsoever sane defaults on ANY platform.
I'm "happy" to say that it's extremely easy to write autotools builds
that are just as broken as the CMake examples you just described.
-- Brane
I doubt its "just as easy" to make it royally fscked up like cmake
have, since most options are pretty well known, tried and tested,
most code can be built with ./configure && make && make install, you
can't do that with that horrid cmake sewer.
You'll never change my mind on that having fought with the shit, now I
avoid it, except mariadb (that can't be helped - at this time) and
clamav (that I could remove if need be), why the cisco folk want to go
all windowsy with clamav, christ knows.
I would like to kindly remind you that in projects under the Apache
Software Foundation we *must* follow the Code of Conduct.
Please refer to:
[[[
2. Be empathetic, welcoming, friendly, and patient. We work together to
resolve conflicts, assume good intentions, and do our best to act in an
empathetic fashion. We may all experience some frustration from time to
time, but we do not allow frustration to result in a personal attack. A
community where people feel uncomfortable or threatened is not a
productive one. We should be respectful when dealing with other
community members as well as with people outside our community.
]]]
and
[[[
5. Be careful in the words that we choose. Whether we are participating
as professionals or volunteers, we value professionalism in all
interactions, and take responsibility for our own speech. Be kind to
others. Do not insult or put down other participants. Harassment and
other exclusionary behaviour are not acceptable. This includes, but is
not limited to:
]]]
That can be found here:
<https://apache.org/foundation/policies/conduct.html>.
I'm sorry but calling a suggested feature "fucked up like cmake"
because you "don't want to fight with this shit" is higly
unproffesional, not kind at all, and you have zero technical arguments
to back your point with.
"I reckon the same morons who are involved in systemd are involved in
cmake" is really not the most polite way when you speak about
opensource devs - volunteers that develop software that runs more than
50% atleast (but probably even more) of all web infrastructure with
what I believe a little or none founding. Even if a piece of software
is not the best we could've seen, don't blame the people.
I encourage you to be more respectful to people and new ideas. If you
don't like a thought that was brought up on the list, form your
constructive argument and we'll have a better conversation than just
calling everyone stupid.
--
Timofei Zhakov
