Re: [RFC PATCH v2 23/24] Documentation: add comparison of build systems

> 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".

>>> +=== 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 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.