4 ms·
Gotta be That Guy: Some of the wisdom from the recent XZ backdoor incident was that cmake was a contributing factor, due to its internal complexity. Some of t
by jgarzik 2y ago
Gotta be That Guy:
Some of the wisdom from the recent XZ backdoor incident was that cmake was a contributing factor, due to its internal complexity.
Some of the current trend is to strip out autotools and cmake, and go back to the basics, because modern OS support is a subset of what was relevant 20 years ago.
- JonChesterfield 2y agoI am deeply sick of "compile and run a program to guess stuff about the environment" as a model. Especially in the context of cross compiling and cmake my patience is totally exhausted. I'm not convinced it's necessary any more. When a compiler claims to implement c99, it probably does implement c99. Lots of ugly target dependent hackery is now fixed at source by doing more sensible things in the target and/or the target having died off decades ago. Libuv does horrendous platform specific stuff on targets I don't recognise, in raw C, and it's totally possible to compile it without doing any configure or cmake style nonsense because the platform specific things are in their own source files. 90% of the target specific stuff I can handle by asking the C preprocessor what it's building. The remaining 10% can be specified by editing a header or passing compiler flags or similar. Right now for C libraries I want to depend on I'm patching the source on import to not need any configure check or magic compiler flags, then building every C file separately into an object with the same invocation, and it is working just fine.