Re: CMake on Unix
Daniel Sahlberg <[email protected]> Fri, 15 May 2026 22:34:51 +0200
| Newsgroups | gmane.comp.apache.apr.devel |
|---|---|
| Message-ID | <CAMHy98OcQUdqSMbQ-sN-aNgMXHKk+2j=+MWRXfBRXMrQjT1gRw@mail.gmail.com> |
--000000000000b7555a0651e125e4 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable fre 15 maj 2026 kl. 21:58 skrev Timofei Zhakov <[email protected]>: > On Fri, May 15, 2026 at 9:28=E2=80=AFPM 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=E2=80=AFPM Noel Butler <noel.butler@ausic= s.net> >>> wrote: >>> > >>> > On 14/05/2026 14:54, Branko =C4=8Cibej wrote: >>> > >>> > Its convoluted. Its messy. >>> > >>> > Lets take sql as a horrid example (but its similar with the only othe= r >>> 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=3D/usr --localstatedir=3D/usr/mysql/data >>> --datadir=3D/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=3D"-O2 -fPIC" -DCMAKE_CXX_FLAGS=3D"-O2 -fPIC" >>> -DFEATURE_SET=3D"community" -DCMAKE_INSTALL_PREFIX=3D/usr -D >>> > INSTALL_LIBDIR=3D"lib64" -DINSTALL_SBINDIR=3Dlibexec >>> -DINSTALL_INCLUDEDIR=3Dinclude/mysql -DINSTALL_MYSQLSHAREDIR=3Dshare/my= sql >>> > -DINSTALL_SQLBENCHDIR=3D"" -DINSTALL_MYSQLTESTDIR=3Dmysql-test >>> -DINSTALL_MANDIR=3Dman -DINSTALL_PLUGINDIR=3D"lib64/mysql/plugin" >>> > -DINSTALL_SCRIPTDIR=3Dbin -DINSTALL_SUPPORTFILESDIR=3Dshare/mysql >>> -DINSTALL_MYSQLDATADIR=3D"/var/lib/mysql" -DMYSQL_DATADIR=3D" >>> > /var/lib/mysql" -DMYSQL_UNIX_ADDR=3D"/var/run/mysql/mysql.sock" >>> -DWITH_EXTRA_CHARSETS=3Dcomplex -DWITH_INNOBASE_STORAGE_ENGI >>> > NE=3D1 -DENABLED_LOCAL_INFILE=3DON -DWITH_LIBARCHIVE=3DON -DWITH_READ= LINE=3DON >>> -DWITH_JEMALLOC=3Dsystem -DWITH_ZLIB=3Dsystem -DWITH_ >>> > EXTERNAL_ZLIB=3DON -DWITH_SSL=3Dsystem -DCONC_WITH_SSL=3DON >>> -DUSE_ARIA_FOR_TMP_TABLES=3DON -DAWS_SDK_EXTERNAL_PROJECT=3DOFF >>> > >>> > Then running make... >>> > >>> > THEN to upgrade each version you have to screw around with garbage li= ke >>> > >>> > 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 olde= r >>> 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 plu= ck >>> out of a tarball >>> > >>> > all because there is no make uninstall.... >>> > >>> > >>> > >>> > And clamav as mentioned earlier, before it was just >>> > >>> > ./configure --prefix=3D >>> > >>> > >>> > 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=3D/usr/local -D >>> CMAKE_INSTALL_LIBDIR=3Dlib64 -D APP_CONFIG_DIRECTORY=3D/etc/clamav -D >>> DATABASE_DIRECTORY=3D/var/lib/clamav >>> > >>> > >>> > you try remembering all that crap when you need to off the top of you= r >>> head, and using a cheatsheet (like we obviously are doing) is not an ex= cuse. >>> > >>> > 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 tw= o >>> 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 d= o >>> 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 clam= av >>> (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 produc= tive >>> 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 ot= her >>> 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" becaus= e >>> you "don't want to fight with this shit" is higly unproffesional, not k= ind >>> 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 t= he >>> 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=E2=80= =99t >> 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. L= ets >> 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 i= s > 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 nev= er > 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 tim= e, > 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=E2=80=99m happy to sponsor this if it to add Unix compatibility to the CM= ake build system. Hack away! Cheers Daniel --000000000000b7555a0651e125e4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"auto">fre 15 maj 2026 kl. 21:58 skrev Timofei Zhakov <<a hre= f=3D"mailto:[email protected]">[email protected]</a>>:<br></div><div dir= =3D"auto"><div class=3D"gmail_quote gmail_quote_container"><blockquote clas= s=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;b= order-left-style:solid;padding-left:1ex;border-left-color:rgb(204,204,204)"= ><div dir=3D"ltr"><div dir=3D"ltr">On Fri, May 15, 2026 at 9:28=E2=80=AFPM = Daniel Sahlberg <<a href=3D"mailto:[email protected]" target= =3D"_blank">[email protected]</a>> wrote:</div><div class=3D"g= mail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0= .8ex;border-left-width:1px;border-left-style:solid;padding-left:1ex;border-= left-color:rgb(204,204,204)"><div dir=3D"auto">fre 15 maj 2026 kl. 21:18 sk= rev Timofei Zhakov <<a href=3D"mailto:[email protected]" target=3D"_blan= k">[email protected]</a>>:<br></div><div dir=3D"auto"><div class=3D"gmai= l_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8e= x;border-left-width:1px;border-left-style:solid;padding-left:1ex;border-lef= t-color:rgb(204,204,204)"><div dir=3D"ltr">On Thu, May 14, 2026 at 12:49=E2= =80=AFPM Noel Butler <<a href=3D"mailto:[email protected]" target= =3D"_blank">[email protected]</a>> wrote:<br>><br>> On 14/05/= 2026 14:54, Branko =C4=8Cibej wrote:<br>><br>> Its convoluted. Its me= ssy.<br>><br>> Lets take sql as a horrid example (but its similar wit= h the only other =C2=A0forced cmake requirement that we use being clamav), = what used to configured and built with autotools could be done as such, cle= ar simple EASY for even the most junior and senior administrator alike to c= onfig from memory -<br>><br>> ./configure --prefix=3D/usr --localstat= edir=3D/usr/mysql/data --datadir=3D/var/lib/mysql<br>><br>><br>> d= one...<br>><br>><br>> BUT cmake to do same thing requires this cra= p (supplied my mariadb team member to mimic our build requirements)<br>>= <br>><br>> cmake -DCMAKE_C_FLAGS=3D"-O2 -fPIC" -DCMAKE_CXX_= FLAGS=3D"-O2 -fPIC" -DFEATURE_SET=3D"community" -DCMAKE= _INSTALL_PREFIX=3D/usr -D<br>> INSTALL_LIBDIR=3D"lib64" -DINST= ALL_SBINDIR=3Dlibexec -DINSTALL_INCLUDEDIR=3Dinclude/mysql -DINSTALL_MYSQLS= HAREDIR=3Dshare/mysql<br>> -DINSTALL_SQLBENCHDIR=3D"" -DINSTAL= L_MYSQLTESTDIR=3Dmysql-test -DINSTALL_MANDIR=3Dman -DINSTALL_PLUGINDIR=3D&q= uot;lib64/mysql/plugin"<br>> =C2=A0-DINSTALL_SCRIPTDIR=3Dbin -DINST= ALL_SUPPORTFILESDIR=3Dshare/mysql -DINSTALL_MYSQLDATADIR=3D"/var/lib/m= ysql" -DMYSQL_DATADIR=3D"<br>> /var/lib/mysql" -DMYSQL_UN= IX_ADDR=3D"/var/run/mysql/mysql.sock" -DWITH_EXTRA_CHARSETS=3Dcom= plex -DWITH_INNOBASE_STORAGE_ENGI<br>> NE=3D1 -DENABLED_LOCAL_INFILE=3DO= N -DWITH_LIBARCHIVE=3DON -DWITH_READLINE=3DON -DWITH_JEMALLOC=3Dsystem -DWI= TH_ZLIB=3Dsystem -DWITH_<br>> EXTERNAL_ZLIB=3DON -DWITH_SSL=3Dsystem -DC= ONC_WITH_SSL=3DON -DUSE_ARIA_FOR_TMP_TABLES=3DON -DAWS_SDK_EXTERNAL_PROJECT= =3DOFF<br>><br>> Then =C2=A0running =C2=A0 =C2=A0make...<br>><br>&= gt; THEN to upgrade each version you have to screw around with garbage like= <br>><br>> rm $(</root/install_manifest-MARIADB.txt)<br>> make = install<br>> cp install_manifest.txt /root/install_manifest-MARIADB.txt<= br>><br>> (Sure you don't need to cp and use /root/install_manife= st but if someone clears out the source code you will be left with pieces o= f older versions, so you copy it, and lets not forget =C2=A0that file is no= t created until the program is built and installed, its not something you c= an pluck out of a tarball<br>><br>> all because there is no make unin= stall....<br>><br>><br>><br>> And clamav as mentioned earlier, = before it was just<br>><br>> ./configure --prefix=3D<br>><br>><= br>> NOW it too requires all the manual rm BS as maria/mysql above, but = at least its CMAKE line is much shorter..<br>><br>><br>> cmake .. = -D CMAKE_INSTALL_PREFIX=3D/usr/local -D CMAKE_INSTALL_LIBDIR=3Dlib64 -D APP= _CONFIG_DIRECTORY=3D/etc/clamav -D DATABASE_DIRECTORY=3D/var/lib/clamav<br>= ><br>><br>> 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.<br>><br>> I reckon the same morons who are involve= d in systemd are involved in cmake, =C2=A012 lines to do with what cron doe= s in 1<br>><br>><br>> /that completes this years rant<br>><br>&= gt;<br>><br>> You just described two horribly broken CMake build syst= ems. In the two cases you mentioned, the fault lies with the authors, not w= ith CMake. :)<br>><br>><br>><br>> yes, its a proble with cmake = (see my end) and if the mariadb team can't get it right as you claim, t= hen its more of a reason to avoid the garbage.<br>><br>><br>><br>&= gt;<br>><br>> Well, except in the sense that CMake has zero, nil, zil= ch, none whatsoever sane defaults on ANY platform.<br>><br>> I'm = "happy" to say that it's extremely easy to write autotools bu= ilds that are just as broken as the CMake examples you just described.<br>&= gt;<br>> -- Brane<br>><br>><br>> I doubt its =C2=A0"just a= s easy" to make it royally fscked up like cmake have, =C2=A0since most= options are pretty well known, tried and tested, most code can be built wi= th ./configure && make && make install, you can't do th= at with that horrid cmake sewer.<br>><br>> 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 k= nows.<br><br><br>I would like to kindly remind you that in projects under t= he Apache Software Foundation we *must* follow the Code of Conduct.<br><br>= Please refer to:<br><br>[[[<br>2. Be empathetic, welcoming, friendly, and p= atient. We work together to resolve conflicts, assume good intentions, and = do our best to act in an empathetic fashion. We may all experience some fru= stration 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 co= mmunity members as well as with people outside our community.<br>]]]<br><br= >and<br><br>[[[<br>5. Be careful in the words that we choose. Whether we ar= e participating as professionals or volunteers, we value professionalism in= all interactions, and take responsibility for our own speech. Be kind to o= thers. Do not insult or put down other participants. Harassment and other e= xclusionary behaviour are not acceptable. This includes, but is not limited= to:<br><div>]]]</div><div><br></div><div>That can be found here: <<span= ></span><a href=3D"https://apache.org/foundation/policies/conduct.html" tar= get=3D"_blank">https://apache.org/foundation/policies/conduct.html</a>>.= </div><br>I'm sorry but calling a suggested feature "fucked up lik= e cmake" because you "don't want to fight with this shit"= ; is higly unproffesional, not kind at all, and you have zero technical arg= uments to back your point with.<br><br><div>"I reckon the same morons = who are involved in systemd are involved in cmake<span>" 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. Ev= en if a piece of software is not the best we could've seen, don't b= lame the people.</span></div><div><br></div><div><span>I encourage you to b= e more respectful to people and new ideas. If you don't like a thought = that was=C2=A0</span><span>brought up on the list</span><span>, form your c= onstructive argument and we'll have a better conversation than just cal= ling everyone stupid.</span></div><br>--<br>Timofei Zhakov</div></blockquot= e><div dir=3D"auto"><br></div><div dir=3D"auto">I would like to say that I = stand behind Timofei I all the above.</div><div dir=3D"auto"><br></div><div= dir=3D"auto">CMake may have its quirks and Brane has made a case that it d= oesn=E2=80=99t provide sensible defaults for many platforms, but I also thi= nk you can create difficult build systems or easy build systems with any to= ol.</div><div dir=3D"auto"><br></div><div dir=3D"auto">Is it more difficult= to create an easy to use build systems with autotools than CMake? I have n= o idea. But we have one individual who is keen on updating the existing CMa= ke build system to also work on Unix. Lets see how it goes and if we can ma= ke it feature compatible and as easy as autotools for the end user.</div><b= r clear=3D"all"></div></div></blockquote><div><br></div><div>Unfortunately,= build systems in C are not perfect as we all=C2=A0know. There is always so= me=20 trade off that we make when choosing one over another,=C2=A0or community pr= eference which is also important. If you'd ask me to, I'd never sto= p naming=20 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 ou= t to be. Whether=C2=A0we like it or not.</div><div><br></div><div>But gener= ally, I think both systems do decently well on Unix. With cmake you can wri= te the same configuration=C2=A0for Unix and Windows at the same time, while= autoconf is generally the most standard way - the classic that everybody k= nows how to work with.</div><div><br></div><div>If it works, nobody complai= ns, and we understand how it works there is really no difference. This is m= y practical opinion. This is something I don't care about in the perfec= t world.</div><div><br></div><div>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 tes= t another platform is present, it's much easier to figure out how it wo= rks than to set up a VM and still deal with the same cmake, although it'= ;s probably not the most accurate example.</div></div></div></blockquote><d= iv dir=3D"auto"><br></div><div dir=3D"auto">I=E2=80=99m happy to sponsor th= is if it to add Unix compatibility to the CMake build system.</div><div dir= =3D"auto"><br></div><div dir=3D"auto">Hack away!</div><div dir=3D"auto"><br= ></div><div dir=3D"auto">Cheers</div><div dir=3D"auto">Daniel</div></div></= div> --000000000000b7555a0651e125e4--