Hi Patrick
On 15/10/2024 13:12, Patrick Steinhardt wrote:
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.
I think that would make sense - anyone who objects to the order you've
selected can also say so in a review.
+=== 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".
That would probably be clearer but as you say it can wait
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.
It's going to take a while for me to get that image out of my mind!
I've reworded this slightly now and added NonStop.
Great
+=== 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."
Ah so this is basically "there should be a way to disable
parallelization and let the test access the terminal"?
+=== 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?
I've not been able to find any documentation but
https://github.com/Kitware/CMake/tree/9c25632ba0ad0525b20195d371b3d78a8bcc4113/Modules/Platform
seems to show which platforms and compilers are supported.
+- 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.
It's an improvement on our Makefile but a regression compared to our
CMakeList.txt which was specifically aimed making it easy for new
contributors to get started without downloading any extra software or
running terminal commands.
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.
Right, I suspect the people who added support for building git in Visual
Studio with CMake have different priorities. It's a real shame the meson
there isn't a meson plugin for Visual Studio.
Best Wishes
Phillip
