Re: [dev] getting rid of cmake builds
On Thu, Sep 21, 2023 at 5:03 PM Dave Blanchard wrote: > I attached an example script which one could use to bootstrap cmake in a > LFS type environment during the initial tool build, or pick and choose the > necessary bits in order to bootstrap a custom cmake on their own live >running system. Thank you. > If you want to write a cmake replacement in tight, robust, well-commented > C that does most everything cmake does, at least for the use case of > Linux/BSD software builds (I don't care about Windows or other platforms), > I'd certainly love to give it a try; but on my own system, from the > perspective of Getting Things Done, I haven't written one, but while trying different build systems, I came across CDetect. It only replaces the configure part of a standard gnu autotools build, not the make part. There's some documentation on it here: https://cdetect.sourceforge.net/ https://github.com/IngwiePhoenix/cDetect/wiki/Documentation:-The-general Considering it's only 3 files (or 4 if you count the one you create for the project that uses them), it does a lot and is much more compact than tools like cmake. I've been using it for my own projects for a while now and if I have issues with building a FLOSS package, I often create my own build by hand with CDetect and make. I've been adding features to the original CDetect such as better support for cross-compiling and hope to upload my own version when I have the time to do so. Thanks to everyone for the interesting comments on build systems. I've been researching the topic for a while since I've never been happy with more commonly used solutions. I'm aware of GNU make (which adds its own special features), POSIX style makes and Plan 9 has mk. I'm curious, for those using a variant of the standard POSIX make, where do you find the source code? The BSD systems have their own version of make and I've seen some very old code for make in Usenet archives. Which do you use and has it been ported to Linux? I've been working on a build system to be able to create reproducible builds. I have a tool that can generate makefiles but at present, it's targeted to GNU make. I'm wondering how much effort would be involved to have it generate files for other versions of make. I'm guessing my biggest hurdle will be dealing with the differences in wildcard syntax. Thanks again. Always find discussions on build systems such an interesting topic since there are a large variety of tools available and each has its own pros and cons.
Re: [dev] getting rid of cmake builds
On Thu, Sep 21, 2023 at 5:03 PM Dave Blanchard wrote: > I attached an example script which one could use to bootstrap cmake in a > LFS type environment during the initial tool build, or pick and choose the > necessary bits in order to bootstrap a custom cmake on their own live >running system. Thank you. > If you want to write a cmake replacement in tight, robust, well-commented > C that does most everything cmake does, at least for the use case of > Linux/BSD software builds (I don't care about Windows or other platforms), > I'd certainly love to give it a try; but on my own system, from the > perspective of Getting Things Done, I haven't written one, but while trying different build systems, I came across CDetect. It only replaces the configure part of a standard gnu autotools build, not the make part. There's some documentation on it here: https://cdetect.sourceforge.net/ https://github.com/IngwiePhoenix/cDetect/wiki/Documentation:-The-general Considering it's only 3 files (or 4 if you count the one you create for the project that uses them), it does a lot and is much more compact than tools like cmake. I've been using it for my own projects for a while now and if I have issues with building a FLOSS package, I often create my own build by hand with CDetect and make. I've been adding features to the original CDetect such as better support for cross-compiling and hope to upload my own version when I have the time to do so. Thanks to everyone for the interesting comments on build systems. I've been researching the topic for a while since I've never been happy with more commonly used solutions. I'm aware of GNU make (which adds its own special features), POSIX style makes and Plan 9 has mk. I'm curious, for those using a variant of the standard POSIX make, where do you find the source code? The BSD systems have their own version of make and I've seen some very old code for make in Usenet archives. Which do you use and has it been ported to Linux? I've been working on a build system to be able to create reproducible builds. I have a tool that can generate makefiles but at present, it's targeted to GNU make. I'm wondering how much effort would be involved to have it generate files for other versions of make. I'm guessing my biggest hurdle will be dealing with the differences in wildcard syntax. Thanks again. Always find discussions on build systems such an interesting topic since there are a large variety of tools available and each has its own pros and cons.
Re: [dev] getting rid of cmake builds
On Fri, 22 Sep 2023 17:08:15 +0200 Mattias Andrée wrote: Dear Mattias, > You can used make to run ./configure automatically, all you need to > do is simply rename Makefile to makefile.in, let ./configure run `ln > -s makefile.in makefile` and create a new file named Makefile > containing: > > .POSIX: > .DEFAULT: > ./configure > $(MAKE) -f makefile $@ > > I think running ./configure isn't a big deal, however this technique > is also very useful if you want to automatically generate rules and > variables for Makefile. it's especially powerful because make(1posix) > expressly states that `-f -` shall be interpreted as using stdin as > the makefile. > > Extremely occasionally POSIX make can feel like it's not enough or at > least not efficient enough (at write time or build time), and GNU > make can fix these issues, however using this double makefile > technique, all of these can be addressed (of course not always as > nicely as non-standard features can). Just look at this beauty: > https://codeberg.org/maandree/simple-icon-theme/src/branch/master/Makefile thank you for your thoughtful response! I also considered this solution, but noticed that it is extremely at odds with today's packaging tools. With best regards Laslo
Re: [dev] getting rid of cmake builds
Hi, On Fri, Sep 22, 2023 at 05:08:15PM +0200, Mattias Andrée wrote: > > You can used make to run ./configure automatically, all you need to do is > simply > rename Makefile to makefile.in, let ./configure run `ln -s makefile.in > makefile` > and create a new file named Makefile containing: > > .POSIX: > .DEFAULT: > ./configure > $(MAKE) -f makefile $@ I used this technique in scc at the beginning (in my case for inclusion dependencies, not for configurE), but it was a bit confusing for people and then I switched it to other solution that I think is worse. Maybe it is time to go back and use this solution again. Regards,
Re: [dev] getting rid of cmake builds
NRK writes: > On Fri, Sep 22, 2023 at 04:07:15PM +0200, Roberto E. Vargas Caballero wrote: > > can you explain me how you solve the problem of duplicated static > > symbols? > > It's not as big of a problem you're making it out to be. Neither dwm or > st for example has duplicated static symbols. No duplicate static symbols, no. It's far worse than that: st/st.c:#define IS_SET(flag)((term.mode & (flag)) != 0) st/x.c:#define IS_SET(flag) ((win.mode & (flag)) != 0) Matthew
Re: [dev] getting rid of cmake builds
On Fri, 22 Sep 2023 15:54:59 +0200 Laslo Hunhold wrote: > On Thu, 21 Sep 2023 16:05:17 +0200 > David Demelier wrote: > > Dear David, > > > It's near to impossible to convert a CMake project to make > > automatically, CMake is almost like a scripting language given the > > numerous of things you can do with it. > > > > Keep in mind that plain make (POSIX) is enough for really simple > > projects but can come limited when going portable. Although the use of > > pkg-config helps there are various places where you will need to pass > > additional compiler/linker flags. For those I like GNU make even > > though its syntax is somewhat strange at some points. > > > > Which projects are you referring to? > > the "POSIX makefiles are not easily portable" aspect hasn't been true > for a long time. Check out the build system of my project libgrapheme. > It is 100% POSIX make and portable across all BSDs, macOS, Cygwin, > MinGW and of course Linux, including automatically naming and embedding > the semantic version as specified in the Makefile. This is done by > providing a very simple ./configure script that automatically modifies > config.mk and tells the user when they are working from a system that > hasn't been ported to yet. You can used make to run ./configure automatically, all you need to do is simply rename Makefile to makefile.in, let ./configure run `ln -s makefile.in makefile` and create a new file named Makefile containing: .POSIX: .DEFAULT: ./configure $(MAKE) -f makefile $@ I think running ./configure isn't a big deal, however this technique is also very useful if you want to automatically generate rules and variables for Makefile. it's especially powerful because make(1posix) expressly states that `-f -` shall be interpreted as using stdin as the makefile. Extremely occasionally POSIX make can feel like it's not enough or at least not efficient enough (at write time or build time), and GNU make can fix these issues, however using this double makefile technique, all of these can be addressed (of course not always as nicely as non-standard features can). Just look at this beauty: https://codeberg.org/maandree/simple-icon-theme/src/branch/master/Makefile > > libgrapheme has automatic unit tests and code generators written in > C99, so it's probably a very extreme example. You could easily adapt a > library project using the libgraphmee configure+config.mk+Makefile as a > basic template. > > Feel free to contact me if you have any questions. > > With best regards > > Laslo > > [0]:https://git.suckless.org/libgrapheme/ >
Re: [dev] getting rid of cmake builds
On Fri, Sep 22, 2023 at 04:07:15PM +0200, Roberto E. Vargas Caballero wrote: > can you explain me how you solve the problem of duplicated static > symbols? It's not as big of a problem you're making it out to be. Neither dwm or st for example has duplicated static symbols. And it's easily solvable by having a slightly more descriptive name (avoiding unnecessary global variables also reduces chances of collision). > Can you explain me where is the complexity? I've already given a list of things on my initial post. But if I need to repeat one of them: Dependency tracking is easily the biggest problem that incremental builds introduce. Which is something that: a) your tiny example makefile did not tackle b) dwm makefile gets wrong as it does not track drw.h nor util.h (dmenu also fails to track util.h as well). Aside from that, unity-build only requires a compiler. A Makefile additionally requires (i) a Make implementation (ii) (usually) a posix compliant shell. Also this conversation feels like it's going in circles with me having to constantly repeat things I've already said, so I'll say this: If you're already convinced that a makefile is better than a unity build, then that's fine. I'm not interested in forcing you to use something else. Nor am I interested in fighting some editor^W build-system war. But I've tried out both makefiles (both simple and "complex" ones) and unity-build and *my* conclusion is that the latter is significantly simpler and superior for small projects - and I've given a list of reason on my initial post. If someone thinks those are valid reasons, then try it out. If not, then don't. - NRK
Re: [dev] getting rid of cmake builds
On 23/09/22 04:27PM, Страхиња Радић wrote: > ...according to sloccount[1]... [1]: https://dwheeler.com/sloccount/ signature.asc Description: PGP signature
Re: [dev] getting rid of cmake builds
On 23/09/22 07:27PM, NRK wrote: > And this is no longer the 50s, we have enough memory to build a couple > thousand line of code without *requiring* splitting things into multiple > intermediate object files to avoid going OOM (even with bloated > compilers like gcc/clang with optimization enabled). It's not about memory, it's more about how easy it is for a human to navigate the source code. Of course, cscope and ctags exist, and reducing the number of lines of code is desired, but it is not always possible to reduce a program below 1k lines of code, so it needs splitting into several units. For example (according to sloccount[1]), my patched dwm fork has ~3.3k lines of C code across 5 .c files, my patched st fork has ~4.9k lines of C code across 2 .c files, and slstatus has ~2k lines of C code. My own programs are close to those numbers: some have up to ~5k lines of code combined only in .c files. signature.asc Description: PGP signature
Re: [dev] getting rid of cmake builds
Hi, On Fri, Sep 22, 2023 at 07:27:25PM +0600, NRK wrote: > $ make > # ... builds st > $ make CFLAGS="-g3 -fsanitize=address,undefined" > # ... builds nothing because make doesn't take CFLAGS changes into > account. > > I've seen some (hacky) ways to dump the flags into a file to trigger > re-build more reliably. But as I've said, it's a solution to a self-made > problem. I don't think a build system should care about it. The build system should care only about building what is required with the set of flags that you pass in the command line. This is derivated from the UNIX principle "Mechanisms, not policy" [1]. What happens if I want to apply the set of flags to only one file? If you want to build everything with a different set of flags just clean and build. This is very well summarized in the quote "Unix was not designed to stop you from doing stupid things, because that would also stop you from doing clever things" [2] > There is no shell script involved. You invoke the compiler directly with > whatever flags you please. There's no need to track dependencies or > flags. Did you see any flags in my example? If I want debug symbols then I just write `make CFLAGS=-g`. and it knows what is the compiler to be used. I don't want to know anything about compiler or set of options, I just want to execute make and get the binary. > And this is no longer the 50s, we have enough memory to build a couple > thousand line of code without *requiring* splitting things into multiple > intermediate object files to avoid going OOM (even with bloated > compilers like gcc/clang with optimization enabled). That is just another version of "it works for me". Don't assume anything about build hosts. If you don't like it you are free of using jave instead, I am pretty sure java programmers would like more this kind of things. > Incremental builds are not free. And for small projects, the complexities > they bring is (IMO) much higher compared to the benefits (which are > either non-existent or negligible for small projects). Do you think the Makefile that I wrote was complex? It was just a list of objects. Can you explain me where is the complexity? and also, can you explain me how you solve the problem of duplicated static symbols? Regards, [1] https://www.linuxtopia.org/online_books/programming_books/art_of_unix_programming/ch01s06_3.html? [2] https://quotefancy.com/quote/1711236/Douglas-Gwyn-Unix-was-not-designed-to-stop-you-from-doing-stupid-things-because-that
Re: [dev] getting rid of cmake builds
On Fri, Sep 22, 2023 at 12:33:15PM +0200, Roberto E. Vargas Caballero wrote: > In a Makefile (in a good well written) you only have to pass a > different CFLAGS value Either I haven't communicated properly, or people are not reading clearly. In either case, here's a practical example using a fresh ST repo: $ make # ... builds st $ make CFLAGS="-g3 -fsanitize=address,undefined" # ... builds nothing because make doesn't take CFLAGS changes into account. I've seen some (hacky) ways to dump the flags into a file to trigger re-build more reliably. But as I've said, it's a solution to a self-made problem. > but in the shell script There is no shell script involved. You invoke the compiler directly with whatever flags you please. There's no need to track dependencies or flags. And this is no longer the 50s, we have enough memory to build a couple thousand line of code without *requiring* splitting things into multiple intermediate object files to avoid going OOM (even with bloated compilers like gcc/clang with optimization enabled). Incremental builds are not free. And for small projects, the complexities they bring is (IMO) much higher compared to the benefits (which are either non-existent or negligible for small projects). > that is not about build systems, is about software design: This is true. But it is also true that when people have a hammer in hand, everything looks like a nail. When someone start off with an over-complicated build system, they tend to also end up over-engineering the software architecture as a result of the build system making it easy to over-complicate things. - NRK
Re: [dev] getting rid of cmake builds
Hi, On Fri, Sep 22, 2023 at 04:06:25PM +0600, NRK wrote: > On Fri, Sep 22, 2023 at 11:18:47AM +0200, Страхиња Радић wrote: > > ./build.sh > > But in short: you simply include any `.c` file into one. There's zero and then you get name collisions because all the static symbols are compiled in a single translation unit. > problem adapting to a different compiler or compiler flags. In fact, > it's *easier* to do than a makefile (which I also said on my previous easier than in a Makefile? In a Makefile (in a good well written) you only have to pass a different CFLAGS value, but in the shell script you have to edit the shell script itself. > $ gcc -o exe src.c > $ clang -o exe src.c # no need to "clean" anything > > Doing cross-platform is also easy by just making your core application > "platform-agonistic" and having the "platform layer" provide platform > specific functionality. For example, here's a hypothetical > `app-windows.c` file: that is not about build systems, is about software design: OBJS = main.o src-$(SYS).o SYS = posix app: $(OBJS) $(CC) -o $@ $(LDFLAGS) $(OBJS) if you compile in posix, then you only use `make`, if you compile in windows you use `make SYS=windows`. Makefiles are really simple, but for some reason that I don't understand people like to write horrible and complex Makefiles. Regards,
Re: [dev] getting rid of cmake builds
On Fri, Sep 22, 2023 at 11:18:47AM +0200, Страхиња Радић wrote: > ./build.sh I did not advocate for `build.sh`. And the wikipedia article I linked explains how unity-builds works pretty well already: https://en.wikipedia.org/wiki/Unity_build But in short: you simply include any `.c` file into one. There's zero problem adapting to a different compiler or compiler flags. In fact, it's *easier* to do than a makefile (which I also said on my previous mail). $ gcc -o exe src.c $ clang -o exe src.c # no need to "clean" anything Doing cross-platform is also easy by just making your core application "platform-agonistic" and having the "platform layer" provide platform specific functionality. For example, here's a hypothetical `app-windows.c` file: #include "app.c" // platform-agonistic application // ... // now add windows specific functionalities and // an entry point (i.e main function) below. And the same for a "app-posix.c". And then you compile in a single command, for example: $ cc -o exe src-posix.c# on posix platforms $ cl src-windows.c [...] # on windows with msvc without requiring mingw or similar - NRK
Re: [dev] getting rid of cmake builds
On 23/09/22 03:09PM, NRK wrote: > Some tend to argue that this "doesn't scale", but as I said, this is for > small projects. And the chances of your small project turning into the > next linux kernel [2] with 30M LoC is probably not high. So don't create > new *actual problems* by trying to solve an imaginary one. The moment there is a new compilation unit, or several of them (but still way below "30M LoC" -- say, utils.c, screen.c and utf8.c), this quickly becomes tedious to type for every unit and a program. And then one puts those commands in ./build.sh. And then it occurs that one needs to adapt to a different compiler, different flags, different PREFIX and so on and ./build.sh gradually becomes less elegant than, say, a mkfile. signature.asc Description: PGP signature
Re: [dev] getting rid of cmake builds
On Fri, Sep 22, 2023 at 10:00:56AM +0200, Страхиња Радић wrote: > How does it decide when rebuilding is needed? Does it track dependencies and > how? IMO in small projects, these are problems that should be *avoided entirely* instead of creating them and then solving it. E.g you can have a simple unity build [0] that builds everything in a single translation-unit via a single compiler command: $ cc -o exe src.c This requires: - No build system whatsoever. - No dependency tracking. - No need to run `make clean` or similar when changing compiler flags (e.g adding Sanitizers, testing with more aggressive warnings or optimization flags etc). - Usually faster full builds (even compared to parallel make) due to not having to re-parse the same system headers again and again along with avoiding other fixed costs. - Nearly as fast as incremental builds or at least not noticeably slower that would hamper developer productivity (reminder: for small projects). - Better warnings due to compiler (and static analyzers) being able to look across TU boundaries. [1] - Simple build makes it easier to use other tools on the project such as static analyzers or fuzzers. Some tend to argue that this "doesn't scale", but as I said, this is for small projects. And the chances of your small project turning into the next linux kernel [2] with 30M LoC is probably not high. So don't create new *actual problems* by trying to solve an imaginary one. [0]: https://en.wikipedia.org/wiki/Unity_build [1]: you can add LTO to overcome this. But then your incremental builds will usually become _significantly slower_ because LTO (as of now at least) makes the linking process extremely slow. [2]: *even in* large projects, unity builds are still useful to speed up compilation. For example the infamous linux kernel "fast header" patches included reducing TUs by, "consolidating .c files": https://lore.kernel.org/lkml/ydifz+lmewets...@gmail.com/T/#u - NRK
Re: [dev] getting rid of cmake builds
On 23/09/22 10:26AM, Sagar Acharya wrote: > You can have inputs like > > ./build.dash rebuild > > which first cleans earlier compiled files and builds. All of the build systems I listed support cleaning and rebuilding as well. > Dependencies would go into logic of shell script, it can have > check_dependencies which checks for files. Normally as you code a shell > script! Of course, one could rewrite any build system, with varying degree of difficulty, in shell script if needed, but then one would a) still write build scripts (Makefiles, .do files...) in that build system, and b) that would be suboptimal. Shell script is not a general-purpose programming language. Just some of the drawbacks of using shell script is that it is a slow, insecure, interpreted language with limited expresiveness. Above all else, it was not designed to be a general-purpose programming language. P.S: https://git-send-email.io/top-posting.html signature.asc Description: PGP signature
Re: [dev] getting rid of cmake builds
You can have inputs like ./build.dash rebuild which first cleans earlier compiled files and builds. Dependencies would go into logic of shell script, it can have check_dependencies which checks for files. Normally as you code a shell script! Thanking you Sagar Acharya https://humaaraartha.in/selfdost/selfdost.html 22 Sept 2023, 13:31 by cont...@strahinja.org: > On 23/09/22 09:50AM, Sagar Acharya wrote: > >> A better way to build is to write a build.dash script >> > > Some elaboration is needed. > > In what way would this shell script be better than the make systems I listed? > How does it decide when rebuilding is needed? Does it track dependencies and > how? >
Re: [dev] getting rid of cmake builds
On 23/09/22 09:50AM, Sagar Acharya wrote: > A better way to build is to write a build.dash script Some elaboration is needed. In what way would this shell script be better than the make systems I listed? How does it decide when rebuilding is needed? Does it track dependencies and how? signature.asc Description: PGP signature
Re: [dev] getting rid of cmake builds
A better way to build is to write a build.dash script It would simply execute in shell. I use this method. It is extremely readable and manageable. Ofc, it cannot be used for other softwares where bloatware is used! Thanking you Sagar Acharya https://humaaraartha.in/selfdost/selfdost.html 22 Sept 2023, 10:17 by cont...@strahinja.org: > On 23/09/21 09:42AM, LM wrote: > >> I build a lot of common libraries and programs from source. Many of >> them are switching to cmake. I'm not a fan of cmake. For one thing, >> it's so complicated to build from source code that I can't bootstrap >> the build of cmake itself. I really would prefer to build as many of >> > > I agree. Anyone who tries to build a LFS system (or a derivation of it) will > inevitably come across the beast that is cmake. When creating build scripts > for > "roll my own" static musl distro, Galeb[1], I came to several conclusions: > > * cmake is a bloated mess (understatement), takes ages to build > * It being written in C++ is part of the reason for the above > * cmake can't properly figure out static library dependencies, in some > cases they still need to be configured manually > > When it comes to the choice of a build system, I know of a number of options > which are way better than cmake (in no particular order): > > - djb redo > - POSIX make > - Plan9 mk > > On topic, I'm afraid I haven't come across any automated converters, and as > others have stated, it probably isn't even possible. I think it would be > easier > to write build scripts for packages using cmake in a simpler build system > from > scratch. > > > [1]: https://strahinja.srht.site/galeb/ >
Re: [dev] getting rid of cmake builds
On 23/09/21 09:42AM, LM wrote: > I build a lot of common libraries and programs from source. Many of > them are switching to cmake. I'm not a fan of cmake. For one thing, > it's so complicated to build from source code that I can't bootstrap > the build of cmake itself. I really would prefer to build as many of I agree. Anyone who tries to build a LFS system (or a derivation of it) will inevitably come across the beast that is cmake. When creating build scripts for "roll my own" static musl distro, Galeb[1], I came to several conclusions: * cmake is a bloated mess (understatement), takes ages to build * It being written in C++ is part of the reason for the above * cmake can't properly figure out static library dependencies, in some cases they still need to be configured manually When it comes to the choice of a build system, I know of a number of options which are way better than cmake (in no particular order): - djb redo - POSIX make - Plan9 mk On topic, I'm afraid I haven't come across any automated converters, and as others have stated, it probably isn't even possible. I think it would be easier to write build scripts for packages using cmake in a simpler build system from scratch. [1]: https://strahinja.srht.site/galeb/ signature.asc Description: PGP signature
Re: [dev] getting rid of cmake builds
[After re-reading that email I see that I should have edited it bit better before posting:] I've used all the mainstream build systems to build thousands of other people's software packages, and a few of my own, so I have a good idea how they each stack up from the usability department at least. All things considered, I find that cmake is a solid build system with few corner cases and surprises. It can be scaled elegantly from the simplest projects to the largest. It's my favorite among the various options. Not that it's perfect, but surely a damn sight nicer to work with than autotools, and better than meson also as it's not built in/dependent on Python (a bloated monstrosity itself), and is overall just less of a pain in the ass to work with. Meson has some annoying quirks and some in my opinion bad features, like automatically assuming an internet connection is available and that it's allowed to use it however it likes. I also like ninja due to its simplicity and speed. Keep in mind that cmake can output ninja files just as easily as makefiles or other options. I'm sympathetic to the "cmake is a huge monolith" argument, as I prefer software that is smaller and simpler when possible. It does have a number of dependencies, but these are generally packages I want on my system anyhow. They are essentially all very basic low level libraries that any Linux workstation should already have. They are also "vendored" i.e. a copy included in the tarball in case you need them for bootstrapping purposes. I attached an example script which one could use to bootstrap cmake in a LFS type environment during the initial tool build, or pick and choose the necessary bits in order to bootstrap a custom cmake on their own live running system. The reason for the cmake tool's long build time which makes it seem so big and bulky is largely due to the use of later C++ standards, which will always slow the build quite a bit in any project which uses them. It's not that the code is bloated, it's that it simply takes longer to compile. The newer the standards, the slower C++ builds get. The 'mold' linker is another great example of a nice tool that just takes forever to build, despite being uncomplicated and clean code, just due to using the latest C++ standards. If cmake were written in C instead, as I wish that it were, it would compile just as fast as the 'make' tool source does. If you want to write a cmake replacement in tight, robust, well-commented C that does most everything cmake does, at least for the use case of Linux/BSD software builds (I don't care about Windows or other platforms), I'd certainly love to give it a try; but on my own system, from the perspective of Getting Things Done, I'm happy to have cmake on my system and wish more software would use it. Dave
Re: [dev] getting rid of cmake builds
I've used all the mainstream build systems to build thousands of other people's software packages, and a few of my own, so I have a good idea how they each stack up from the usability department at least. All things considered, over the course of building many thousands of packages with it (including some of my own) I find that cmake is a solid build system with few corner cases and surprises. It can be scaled elegantly from the simplest projects to the largest. It's my favorite among the various options. Not that it's perfect, but surely a damn sight nicer to work with than autotools, and better than meson also as it's not built in/dependent on Python (a bloated monstrosity itself), and is overall just less of a pain in the ass to work with. It has some annoying quirks and some in my opinion bad features, like automatically assuming an internet connection is available and that it's allowed to use it however it likes. I also like ninja due to its simplicity and speed. Keep in mind that cmake can output ninja files just as easily as makefiles or other options. I'm sympathetic to the "cmake is a huge monolith" argument, as I prefer software that is smaller and simpler when possible. It does have a number of dependencies, but these are generally packages I want on my system anyhow. They are essentially all very basic low level libraries that any Linux workstation should already have. They are also "vendored" i.e. a copy included in the tarball in case you need them for bootstrapping purposes. I attached an example script which one could use to bootstrap cmake in a LFS type environment during the initial tool build, or pick and choose the necessary bits in order to bootstrap a custom cmake on their own live running system. The reason for the cmake tool's long build time which makes it seem so big and bulky is largely due to the use of later C++ standards, which will always slow the build quite a bit in any project which uses them. It's not that the code is bloated, it's that it simply takes longer to compile. The newer the standards, the slower C++ builds get. The 'mold' linker is another great example of a nice tool that just takes forever to build, despite being uncomplicated and clean code, just due to using the latest C++ standards. If cmake were written in C instead, as I wish that it were, it would compile just as fast as the 'make' tool source does. If you want to write a cmake replacement in tight, robust, well-commented C that does most everything cmake does, at least for the use case of Linux/BSD software builds (I don't care about Windows or other platforms), I'd certainly love to give it a try; but on my own system, from the perspective of Getting Things Done, I'm happy to have cmake on my system and wish more software would use it. Dave cmake.EXAMPLE Description: Binary data
Re: [dev] getting rid of cmake builds
Am Thu, Sep 21, 2023 at 04:05:17PM +0200 schrieb David Demelier: > Hi, > > It's near to impossible to convert a CMake project to make > automatically, CMake is almost like a scripting language given the > numerous of things you can do with it. > > Keep in mind that plain make (POSIX) is enough for really simple > projects but can come limited when going portable. Although the use of > pkg-config helps there are various places where you will need to pass > additional compiler/linker flags. For those I like GNU make even though > its syntax is somewhat strange at some points. > Leaving aside the question of whether POSIX Make is enough for complex projects, I do concur that it is not a good fit for a cmake conversion. If I was tasked with this, I would probably attempt to build a parser for cmake files (in what language is undecided). And that parser can then output a shell script that does the same thing as what cmake would do, i.e. generate a makefile. If necessary, find other packages by whatever rules and write the results into the makefile. I've switched to ninja-build for some of my projects, and that is pretty awesome. Very fast compared to make. The developers basically took the suckless approach and cut everything out of make that made it slow. The result is incompatible but so much faster. I mention this because the approach of generating a makefile is highly encouraged with ninja, so I just use a shell script for that (and I do my best to keep it portable). That said, portability is really not my goal. I don't actively prevent my stuff from running on non-Linux platforms, but I don't actively seek to have them run and tested, either. So maybe someone with experience on that field should speak up. Ciao, Markus
Re: [dev] getting rid of cmake builds
On 2023-09-21 14:42, LM wrote: I build a lot of common libraries and programs from source. Many of them are switching to cmake. I'm not a fan of cmake. For one thing, it's so complicated to build from source code that I can't bootstrap the build of cmake itself. I really would prefer to build as many of my tools from source as possible and that includes the build system. I've been attempting to create makefiles by hand for some of these programs and libraries that now use cmake. Does anyone have an easy or automated way to convert a cmake build to makefiles or another less complicated build system? Is anyone else trying to simplify their build scripts for commonly used libraries or programs? Is there a way to automate the processes or share effort on this? Thank you. You could try building cmake as per https://www.linuxfromscratch.org/blfs/view/svn/general/cmake.html You just have to backtrack the listed dependencies but if you are trying to build many things from source you must be used to doing that. Eric
Re: [dev] getting rid of cmake builds
On Thu, 2023-09-21 at 09:42 -0400, LM wrote: > I build a lot of common libraries and programs from source. Many of > them are switching to cmake. I'm not a fan of cmake. For one thing, > it's so complicated to build from source code that I can't bootstrap > the build of cmake itself. I really would prefer to build as many of > my tools from source as possible and that includes the build system. > I've been attempting to create makefiles by hand for some of these > programs and libraries that now use cmake. Does anyone have an easy > or automated way to convert a cmake build to makefiles or another > less > complicated build system? Is anyone else trying to simplify their > build scripts for commonly used libraries or programs? Is there a > way > to automate the processes or share effort on this? Thank you. > Hi, It's near to impossible to convert a CMake project to make automatically, CMake is almost like a scripting language given the numerous of things you can do with it. Keep in mind that plain make (POSIX) is enough for really simple projects but can come limited when going portable. Although the use of pkg-config helps there are various places where you will need to pass additional compiler/linker flags. For those I like GNU make even though its syntax is somewhat strange at some points. Which projects are you referring to? -- David
[dev] getting rid of cmake builds
I build a lot of common libraries and programs from source. Many of them are switching to cmake. I'm not a fan of cmake. For one thing, it's so complicated to build from source code that I can't bootstrap the build of cmake itself. I really would prefer to build as many of my tools from source as possible and that includes the build system. I've been attempting to create makefiles by hand for some of these programs and libraries that now use cmake. Does anyone have an easy or automated way to convert a cmake build to makefiles or another less complicated build system? Is anyone else trying to simplify their build scripts for commonly used libraries or programs? Is there a way to automate the processes or share effort on this? Thank you.
