[timeinput]

This 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.

[ahartmetz]

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.

[gravypod]

And, in general, adding a source file can automatically insert a record into the build system if you follow a convention.

[lbayes]

Couldn't a build system use a hash of the accumulated files as a cache key and rebuild it's internal state when that changes?

I'm not seeing a big downside, but maybe I'm missing something obvious.

[kevin_thibedeau]

> 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.

[rualca]

Frankly, with the inception of modern CMake over a decade ago, the only reason anyone has to stray out of cmake's DSL happy path, comprised of all the tried and true declarative bits, is whether

a) they have to do a very niche/specialized/extremely custom extension to CMake, or

b) they have no idea what they are doing.

More often than not, b) is the case.

[MaxBarraclough]

You and I discussed exactly this 3 months back. I won't restate my responses here, but for anyone curious: https://news.ycombinator.com/item?id=26722717

[wheybags]

They recently added a CONFIGURE_DEPENDS flag to file(GLOB...), which will automatically rebuild the file list when new files are added.

[humanrebar]

...which comes with a cost (extra reconfiguration of the project), but it 's worth it for many projects.

[mucholove]

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?

[yongjik]

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.

[ungamedplayer]

A better solution is to a checkout of your build, then you wont have foo.py and you can be sure you haven't missed anything.

[yongjik]

That would work only if you always build after committing all your changes, which is IMHO another anti-pattern.

[ungamedplayer]

Er, but OP's tars up and ship after every change?

Get out of here with your antipatterns.