On Mon, Oct 14, 2024 at 04:23:33PM +0100, Phillip Wood wrote: > On 09/10/2024 15:57, Patrick Steinhardt wrote: > > +== Requirements > > + > > +The following subsections present a list of requirements that we have for any > > +potential build system. Sections are sorted by decreasing priority, even though > > +these priorities will naturally differ between users. > > This last sentence sounds a bit self contradictory - whose priorities are we > using? I guess it's priorities as received by the author, namely me. I didn't quite know how to write this, as I didn't want to force my own prios on everybody else without saying so. But if people agree with the general ordering I'm happy to drop this sentence. > > +=== Platform support > > + > > +The build system must have support for all of our primary platforms as outlined > > +by. These platforms are: > > Something seems to have been lost when the first sentence was edited. > > > + - Linux > > + - Windows > > + - macOS > > + > > +Furthermore, the build system should have support for the following secondary > > +platforms: > > + > > + - AIX > > + - FreeBSD > > + - NetBSD > > + - OpenBSD > > + > > +The platforms which must be supported by the tool should be aligned with our > > +[platform support policy](platform-support.txt). > > The platform support document does not use the terms primary or secondary > when talking about support so I'm not sure what distinction we're trying to > make here. Also where does NonStop fit into this? Yes, true, and that's an issue from my point of view. I think we should make explicit the different kinds of support we have and have a proper list of systems that are supported and their general "support tier". Anyway, that's a different can of worms that I don't want to open right now. My table is still crawling with worms from previously-opened cans. I've reworded this slightly now and added NonStop. > > +=== Ease of use > > + > > +The build system should be both easy to use and easy to extend. While this is > > +naturally a subjective metric it is likely not controversial to say that some > > +build systems are considerably harder to use than others. > > The tricky part is deciding how to measure ease of use if we're going to use > it as a metric for selecting a build system. Yup. It's part of the reason why I wanted to have all build systems in the tree, such that it is possible to compare them by just having a look for how it looks like. Things are naturally going to be subjective, and that is fine. But I guess that we can mostly agree on some general things, like "autoconf looks like gibberish". > > +=== Language support > > + > > +The following languages and toolchains are of relevance and should be supported > > +by the build system: > > + > > + - C: the primary compiled language used by Git, must be supported. Relevant > > + toolchains are GCC, Clang and MSVC. > > + - Rust: candidate as a second compiled lanugage, should be supported. Relevant > > + toolchains is the LLVM-based rustc. > > + > > +Built-in support for the respective languages is preferred over support that > > +needs to be wired up manually to avoid unnecessary complexity. Native support > > +includes the following features: > > + > > + - Compiling objects. > > + - Dependency tracking. > > + - Detection of available features. > > + - Discovery of relevant toolchains. > > + - Linking libraries and executables. > > Do we want a section about templating (i.e. substituting @XXX@) support > which we use when installing scripts? It doesn't hurt. > > +=== Test integration > > + > > +It should be possible to integrate tests into the build system such that it is > > +possible to build and test Git within the build system. Features which are nice > > +to have: > > + > > + - Track build-time dependencies for respective tests. Unit tests have > > + different requirements than integration tests. > > + - Allow filtering of which tests to run. > > + - Allow interactive tests that drop the user into a shell with `test_pause` or > > + `debug`. > > Does this last point mean we want to be able to selectively pass > --interactive to the test script(s) being run? What I mean by this is that when I see that a specific test fails, I want to be able to execute only that single test such that things like `test_pause` fail. What I don't mean is that the build system should know to automatically rerun failing tests with that. I've reformulated it to "Allow running tests such that utilities like `test_pause` or `debug` work." > > +=== CMake > > + > > +- Platform support: not as extensive as GNU Make or autoconf, but all major > > + platforms are supported. > > + - AIX > > + - Cygwin > > + - FreeBSD > > + - Linux > > + - OpenBSD > > + - Solaris > > + - Windows > > + - macOS > > This matches the list in the CMake README but in practice it is available > for a much wider range of platforms including all those listed below for > meson. I was searching for an official statement, but couldn't find anything. Do you maybe have a pointer? > > +- Ease of use: easy to use, discovering available options is not always > > + trivial. The scripting language used by CMake is somewhat cumbersome to use, > > + but extending CMake build instructions is doable. > > +- IDE support: natively integrated into Microsoft Visual Studio. Can generate > > + project descriptions for Xcode. An extension is available for Visual Studio > > + Code. Many other IDEs have plugins for CMake. > > +- Out-of-tree builds: supported. > > +- Cross-platform builds: supported. > > +- Language support: > > + - C: Supported for GCC, Clang, MSVC and other toolchains. > > + - Rust: No built-in support, needs to be wired up manually. > > +- Test integration: supported, even though test dependencies are a bit > > + cumbersome to use via "test fixtures". Interactive test runs are not > > + supported. > > + > > +=== Meson > > + > > +- Platform: not as extensive as GNU Make or autoconf, but all major platforms > > + and some smaller ones are supported. > > + - AIX > > + - Cygwin > > + - DragonflyBSD > > + - FreeBSD > > + - Haiku > > + - Linux > > + - NetBSD > > + - OpenBSD > > + - Solaris > > + - Windows > > + - macOS > > +- Ease of use: easy to use, discovering available options is easy. The > > + scripting language is straight-forward to use. > > +- IDE support: Supports generating build instructions for Xcode and Microsoft > > + Visual Studio, a plugin exists for Visual Studio Code. > > This is my main concern about meson - it means we either loose the nice > integration on Windows that we have with CMake or we have to continue to > maintain both. As I understand it Microsoft Visual Studio support requires > the user to open a mingw terminal and run some to generate a build > description which they can then use form the GUI which is what the CMake > support was added to avoid. I guess they also need to install meson somehow > as well. I'm personally not particularly worried about having to generate the MSVC solution from the command line once, as long as things just work from thereon without requiring the developer to jump through hoops to get it set up. It certainly doesn't seem like a particularly high barrier to me, and should be a huge improvement compared to our current Makefile. I'm mostly there by now with the subprojects added in this version of the patch series, which make it way easier to use MSVC without all deps having been installed. But I still have to port over the SANE_TOOL_PATH hack that we have in CMake. I do understand that just clicking a button to import a CMakeLists.txt is easier. It's mostly that I personally value the sanity that Meson brings with it higher, which is of course a subjective opinion. Patrick
