Comment by ludocode | Hacker News Reader

Comment by ludocode | Hacker News Reader

Parent Full thread

> 4. Perhaps the most egregious missing weakness from TFA is acknowledgement that configure scripts are horrifically slow. It's 2022 and developers have their time wasted by configure checking whether printf() exists.

I'd say on some platforms "horrifically slow" is an understatement. At my day job we were building software in Cygwin on Windows machines infected with Symantec's virus scanner which adds hundreds of milliseconds to every process launch. The configure script for Protocol Buffers took something like half an hour to run.

We eventually switched to CMake but not without a lot of pain first. For what it's worth, CMake fixes the speed issue but not much else. It still has its own totally esoteric custom language, it still discourages globbing source files and requires re-running upon adding any file or changing anything, and it has even more insane default settings than autotools (for example file(DOWNLOAD) from an https:// URL by default ignores certificates!)

There is something wrong with all of these buildsystems. I don't know what the solution is but I feel we are very far from it.

> It still has its own totally esoteric custom language, it still discourages globbing source files and requires re-running upon adding any file

We use cmake, with Windows as our main (but not the only) target platform. We found that not globbing is slow and impractical for us.

1. We generate VS project files, which then guides the build process. When you add source files using the IDE, the generated project(s) will be updated, no regenerate is triggered, the build system will do the correct thing: only the added file, not everything is (re-)built.

2. If we didn't glob, then given the nice local workflow above, people would often forget to update the cmake files and get CI failures.

3. When injecting cmake regeneration into the build process, then for some strange reason we found a bad serialization of build steps, which slows everything down.

4. The slow part on Windows seems to be that cmake has to use some system call to figure out if source file name casing is correct, which is very slow (for us the slowest part of the generation process by far). I don't recall the details here, but I think globbing somewhat reduces this issue.

All in all, I can say: figure out what works best for you and don't trust experts that discourage globbing altogether.

I'm all for bashing autotools, but in this one case, I'd throw Symantec (SEP?) into the fire first.

And the solution to all build systems being bad is imho not to use C/C++. It's model for platform independence is fundamentally broken. It's not like snafu doesn't exist elsewhere too (Python), but other systems are clearly less troublesome (Go, NPM, Cargo).

> it still discourages globbing source files and requires re-running upon adding any file or changing anything

Globbing is discouraged exactly for the reason that then cmake can't discover when files should be added or removed from the build process, or build options have changed. But if globbing isn't used there's no reason why manually re-running cmake would be required (there have been some problems in the past with Visual Studio not automatically reloading a modified project, but I haven't seen those problems in a long time).

You could try Shake. It's a sane build system written by a former co-worker of mine. https://shakebuild.com/

you can also try xmake. It use lua, not DSL.

https://github.com/xmake-io/xmake

Reply on news.ycombinator.com