On Sun, Sep 22, 2024 at 10:01:32PM -0400, Eli Schwartz wrote: > On 9/20/24 10:21 AM, Taylor Blau wrote: > > Modern Build System > > =================== > > > > (moderator: Patrick; notetaker: brian) > > > > * Patrick: three different build system; should get rid of at least one > > of them > > * Should delete autoconf because it's not really maintained > > * Think about a proper build system > > * Obvious choice: cmake > > * Taylor: What's the problem with Makefiles > > * Patrick: Non-standard > > * Meson is nicer than cmake as an alternative > > > I suppose I'm pretty biased but yes, I do feel we (meson) have managed > to make some great workflow improvements here. :) > > Please do feel free to ask me questions about it. > > > > * Jonathan: xz compromise shows autoconf is a risk > > * Autoconf isn't a problem for distro > > * Taylor: distro builds that can't handle "make" without configure are a > > distro problem > > > Anyone can handle "make" without configure without breaking a sweat, > that isn't even remotely challenging, and every distro already does it. > The problem is that "make" is stateless, which is another way of saying > it has amnesia. By that token, everyone cobbles together their own state > system on top of "make". > > Admittedly, once set up it doesn't require much maintenance from version > bump to version bump. > > > > * Jonathan: Modern build system can reflect the structure of how your > > code is set up > > * Declared dependencies > > * Brian: Rust will make the decision for us: cargo > > > I would just like to note that this is not really true. There is one > other build system that supports rust and its name is... meson. :) > > Meson supports rust as a language for creating libraries (cdylib or > rlib) and executables. You can import a crate from crates.io and meson > will synthesize the build system from the existing Cargo.toml to expose > it as an rlib dependency. > > You still get full build script option parsing, system probing, control > flow etc using the meson.build DSL, you can freely mix libraries or > executables in any of meson's supported languages (C, C++, Cython, C#, > D, Fortran, java, ObjC, Rust, swift, Vala...), process custom commands > for data files, run gettext on translations, and more. Meson is designed > to be a polyglot build system in ways that cargo will probably never be. > > Cargo is probably best thought of as a compiler wrapper: it can spit out > an executable if you run it on *.rs sources, but it doesn't replace most > of the interesting parts of a build system and it doesn't even provide > an "install" rule. No, `cargo install` does not count unfortunately as > it has a nasty habit of recompiling the binaries you already compiled, > but now with the wrong options. > > You really want something that provides a project lifecycle workflow for > building, testing, installing, and making dist tarballs with integrated > distcheck. The current Makefiles mostly kind of work, given sufficient > care, but cargo provides exactly zero of anything so you're back to > cobbling together your entire workflow using Makefiles wrapped around > cargo. I would call that the very furthest opposite from "make the > decision for us". > > > > * BSDs use Make (granted, not GNU make) for building > > * Patrick: Is anyone else in favour of a proper build system > > * Ninja is way faster than make to build the projects > > > It is! Yes. Mostly because it does very, very little other than execute > a precalculated build graph, whereas the current Makefile runs a bunch > of stateless external commands each time in order to calculate top-level > Make variables. > > > > * Taylor: Feels odd to build with a fancy tool that might have a > > dependency on Git > > * Dscho: --help is a autoconf feature and removed features are detected > > * Patrick: Isn't that an argument for cmake over autoconf? Dscho: yes > > > cmake does not have an equivalent of ./configure --help. The best you > can get is to try to somehow successfully configure cmake once, and then > run a cmake command that prints every internal control flow variable > used by cmake, then hope that the ones you care about include descriptions. > > (Say what you will about GNU autotools but they knew very well how to > write good interaction standards, as evidenced by all the Makefile > variables git.git already uses from the GNU Coding Standards docs on how > to architect a release process.) It is fundamental to the UX design of > ./configure that a user may query the build system to find out what > choices they can / are expected to make, before committing to those choices. > > cmake is actively a severe regression compared to autoconf for these > purposes. > > > > * Kyle: Editor integration is useful > > * brian: standard structure is helpful for LSPs > > > These tend to mostly be solved by compile_commands.json, which most > modern build systems can produce. In particular, anything that creates a > ninja file essentially gets you this for free, because ninja can create > one for you. > > Plain Makefiles, and GNU automake, don't do very well at this at all, > since Make has too irregular a build graph to reliably compute any such > thing. Same reason why there isn't much in the way of dedicated editor > integration (both cmake and meson have introspection APIs which editor > plugins can use to directly query info from the build system, to provide > finer-grained control than what compile_commands.json can do). > > > > * Emily: libification has shown that makefile is cumbersome > > * Jonathan: Should we do a comparison of build systems in terms of what > > we need from them on the list? Similar to > > Documentation/technical/unit-tests.txt > > * Patrick: I can write such a thing. > > * Patrick: Are their any features we need to consider? > > * Johannes Sixt: Consider supported platforms > > * Patrick: Want to verify that cmake is up to the task by testing in CI? > > * Will volunteer to post something to the list Thanks for your input, Eli, I highly appreciate it to get feedback from a distro maintainer's point of view! I'm not going to answer here, because there already is an ongoing thread at [1]. So I'd propose to consolidate it into that thread. I've put you into Cc there. Patrick [1]: <GV1PR02MB848925A79A9DD733848182D58D662@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx>
