Comment by psyclobe
Comment by psyclobe 3 months ago
cmake ftw
Comment by psyclobe 3 months ago
cmake ftw
Just tried reconfiguring LLVM:
27.24s user 8.71s system 99% cpu 36.218 total
Admittedly the LLVM build time dwarfs the configuration time, but still. If you're only building a smaller component then the config time dominates: ninja libc 268.82s user 26.16s system 3246% cpu 9.086 total
... can cargo build things that aren't rust? If yes, that's really cool. If no, then it's not really in the same problem domain.
No it can't.
It can build a Rust program (build.rs) which builds things that aren't Rust, but that's an entirely different use case (building non-Rust library to use inside of Rust programs).
There's GprBuild (Ada tool) that can build C (not sure about C++). It also has more elaborate configuration structure, but I didn't use it extensively to tell what exactly and how exactly does it do it. In combination with Alire it can also manage dependencies Cargo-style.
still slow, even if it does multiple processes - lots of "discovery" that are only on your machine, or whatever the CI machine had in mind. Instead it should be - "You should expect this, that and that", and by nature of building it - it fails.
Discovery is the wrong thing to do nowadays.
I don't think I'd want a "fail late with a possibly unclear error" build system. There is also the problem that finding the path of dependencies happens at the same time as finding if you have them, and removing one without the other doesn't seem to be very useful.
At best, I think you could have a system that defers some / most dependency discovery until after configure time, but still aborts the build with "required libfoo >= 0.81.0 not found" if necessary.
And no, you are not going to be able to tell everyone exactly where everything needs to be installed unless it's an internal product.
Or meson is a serious alternative to cmake (Even better than cmake imho)