fre 15 maj 2026 kl. 21:58 skrev Timofei Zhakov <[email protected]>: > On Fri, May 15, 2026 at 9:28 PM Daniel Sahlberg < > [email protected]> wrote: > >> fre 15 maj 2026 kl. 21:18 skrev Timofei Zhakov <[email protected]>: >> >>> 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 >>> >> >> I would like to say that I stand behind Timofei I all the above. >> >> CMake may have its quirks and Brane has made a case that it doesn’t >> provide sensible defaults for many platforms, but I also think you can >> create difficult build systems or easy build systems with any tool. >> >> Is it more difficult to create an easy to use build systems with >> autotools than CMake? I have no idea. But we have one individual who is >> keen on updating the existing CMake build system to also work on Unix. Lets >> see how it goes and if we can make it feature compatible and as easy as >> autotools for the end user. >> >> > Unfortunately, build systems in C are not perfect as we all know. There is > always some trade off that we make when choosing one over another, or > community preference which is also important. If you'd ask me to, I'd never > stop naming downsides that either of them have. Of course the only good > build system is the vanilla pure make but it's not how the modern real > world turned out to be. Whether we like it or not. > > But generally, I think both systems do decently well on Unix. With cmake > you can write the same configuration for Unix and Windows at the same time, > while autoconf is generally the most standard way - the classic that > everybody knows how to work with. > > If it works, nobody complains, and we understand how it works there is > really no difference. This is my practical opinion. This is something I > don't care about in the perfect world. > > However, my main point was lost; I'm NOT proposing switching to cmake > completely. I only suggest making it work on Unix *as well*. I think all > can agree that when an option to somehow test another platform is present, > it's much easier to figure out how it works than to set up a VM and still > deal with the same cmake, although it's probably not the most accurate > example. >
I’m happy to sponsor this if it to add Unix compatibility to the CMake build system. Hack away! Cheers Daniel
