Re: [RFC PATCH 1/2] Add C TAP harness

From: Phillip Wood <phillip.wood123@gmail.com>
Date: May 18, 2023, 10:04 UTC
Message-ID: <339c7b51-43de-2d48-d9d2-a2ffeb917e8a@gmail.com>
In-Reply-To: <kl6lpm76zcg7.fsf@chooglen-macbookpro.roam.corp.google.com>

On 12/05/2023 00:16, Glen Choo wrote:

Show 18 quoted lines

> Phillip Wood <phillip.wood123@gmail.com> writes:
> 
>> It would be possible, but I'd want to see some macros for checking
>> invariants that print the source location as well as their
>> arguments. I'd be interested to hear what you think of the alternative
>> approach in the patch below.
> 
> I personally (not representing the Google folks as a whole) find the
> option of implementing our own C TAP suite quite appealing. As your
> patch shows, we can get pretty far even with a rudimentary initial
> version, and I don't see why we couldn't refine it as we go along.
> 
> I'm concerned about the overhead of relying on a third party library
> that implements something moderately complex and isn't widely used,
> It's much easier to patch and read code that we maintain ourselves, e.g.
> if we need to fix bugs/add features/understand its behavior. These risks
> are quite real, especially when it's not clear what kind of support we
> can rely on from C TAP Harness's side.

Yes I think for something like this the advantages of having our own implementation that implements exactly what we want and runs on all the platforms we support outweigh the effort of writing the implementation. As there is already talk of having to customize c-tap-harness it is not clear there is even much effort saved going that route.

Best Wishes

Phillip