CMake Part 1 – The Dark Arts
blog.feabhas.com
CMake Part 1 – The Dark Arts
1–10 of 70 posts
Re: CMake Part 1 – The Dark Arts
#2This is a pretty nice article. CMake is a pretty nice tool and this is a good article for its good parts.
One thing I *hate* with build systems is having to enumerate all of my files. I have a file system. It knows about the files. If I organize my code appropriately (say a lib, inc, and prog directory) the organization says how to build the source code.
I often make my build system support finding all the files in directories, and enumerating them and using them for the build targets.
Some times that scheme bites me when projects get very large, since it can take a while to `find` all the files, but those projects suck to enumerate all the files in too.
Re: CMake Part 1 – The Dark Arts
#3This is a pretty nice article. CMake is a pretty nice tool and this is a good article for its good parts. One thing I *hate* with build systems is having to enumerate all of my files. I have a file system. It knows about the files. If I organize my code appropriately (say a lib, inc, and prog directory) the organization says how to build the source code. I often make my build system support finding all the files in d…
The main reason why not enumerating all the files in the build system is a bad idea is that the build system won't know to rerun itself and re-scan dependencies after you added a file. If you do enumerate the files, you need to change a build system file to add an entry for the new source code file, and that tells the build system to rerun itself and re-scan dependencies. And in the grand order of things, adding a file to the build system is a triviality compared to actually writing the code in it.
Re: CMake Part 1 – The Dark Arts
#4This is a pretty nice article. CMake is a pretty nice tool and this is a good article for its good parts. One thing I *hate* with build systems is having to enumerate all of my files. I have a file system. It knows about the files. If I organize my code appropriately (say a lib, inc, and prog directory) the organization says how to build the source code. I often make my build system support finding all the files in d…
The main reason why not enumerating all the files in the build system is a bad idea is that the build system won't know to rerun itself and re-scan dependencies after you added a file. If you do enumerate the files, you need to change a build system file to add an entry for the new source code file, and that tells the build system to rerun itself and re-scan dependencies. And in the grand order of things, adding a fi…
And, in general, adding a source file can automatically insert a record into the build system if you follow a convention.
Re: CMake Part 1 – The Dark Arts
#5This is a pretty nice article. CMake is a pretty nice tool and this is a good article for its good parts. One thing I *hate* with build systems is having to enumerate all of my files. I have a file system. It knows about the files. If I organize my code appropriately (say a lib, inc, and prog directory) the organization says how to build the source code. I often make my build system support finding all the files in d…
> CMake is a pretty nice tool
It's pretty powerful. It'd be pretty nice if it didn't have such a god awful DSL.
Re: CMake Part 1 – The Dark Arts
#6This is a pretty nice article. CMake is a pretty nice tool and this is a good article for its good parts. One thing I *hate* with build systems is having to enumerate all of my files. I have a file system. It knows about the files. If I organize my code appropriately (say a lib, inc, and prog directory) the organization says how to build the source code. I often make my build system support finding all the files in d…
I use GNUstep on Linux and I generate my main GNUmakefile. They have a preamble file I use that is only generated if it does not exist and it allows me to keep all my settings. The biggest drawback is that I haven’t been able to keep private headers private so everything is public. Would only really be a problem if I was publishing a framework for others to use. I love this system. Makes it very nice to have everything organized in folders as needed and then BAM just run cd/generate/make and done.
How do you differentiate which headers should go where in your script?
Re: CMake Part 1 – The Dark Arts
#7Great write-up. I learnt a lot.
Re: CMake Part 1 – The Dark Arts
#8CMake is legitimately the worst software I've ever used.
cargo > Bazel > autotools > "the IDE" > handwritten Makefiles >>>>>> build.sh >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> CMake
Re: CMake Part 1 – The Dark Arts
#9This is a pretty nice article. CMake is a pretty nice tool and this is a good article for its good parts. One thing I *hate* with build systems is having to enumerate all of my files. I have a file system. It knows about the files. If I organize my code appropriately (say a lib, inc, and prog directory) the organization says how to build the source code. I often make my build system support finding all the files in d…
I've been burnt by that convention pretty regularly:
(1) build automatically scans and adds all files in a directory
(2) I write a quick script foo.py in the directory to check something
(3) Boom, binary contains foo.py
I try to manually enumerate all files whenever I touch a build file.
Re: CMake Part 1 – The Dark Arts
#10CMake is legitimately the worst software I've ever used. cargo > Bazel > autotools > "the IDE" > handwritten Makefiles >>>>>> build.sh >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> CMake
handwritten makefiles have a certain kind of deep, pure beauty if you are in the right mindset