Place all program objects under a single hierarchy

[bonzini]

This cleans up OverrideProgram and OverrideExecutable, replacing them with a single class that is a sibling of ExternalProgram. The two classes are a mess and complicate type annotations noticeably; this change removes the complication and even removes the need for a type alias, because you can almost always just use Program instead of ExternalProgram | Executable | OverrideProgram.

Extracted from #15107, removing support for depends/depend_files (not yet supported by find_program()) and for the ill-fated local_program() function.

Fixes: #15080

[xclaesse]

It's sad that you're reimplementing what I did already just because @eli-schwartz reverts commits he doesn't like. I'm disappointed to see so much work wasted, really discouraging.

[bonzini]

A lot of this work was anyway on top of yours, so there's not much reimplementation. I don't think it's productive either to complain.

[xclaesse]

A lot of this work was anyway on top of yours, so there's not much reimplementation.

Please rebase on top of #15133 then. I removed public API so it is already reviewed and ready to go. That's easier than trying to find out what you modified in my code, or what you recommited under your name.

I don't think it's productive either to complain.

Yes I think it's important to complain, what @eli-schwartz did is extremely frustrating and a waste of everyone's time.

[eli-schwartz]

It's sad that you're reimplementing what I did already just because @eli-schwartz reverts commits he doesn't like. I'm disappointed to see so much work wasted, really discouraging.

I don't think it's productive either to complain.

Yes I think it's important to complain, what @eli-schwartz did is extremely frustrating and a waste of everyone's time.

I find this discussion highly disappointing. For a couple reasons. But the biggest reason is because I heavily object to your immature libel.

I don't want to get into a fight about this. But if you're determined to force my hand, then I feel I need to point out for the record:

When you submit a PR for which there is strong technical disagreement, it is unfortunate but understandable that such things happen. Not everyone always needs to agree, and we can try to negotiate or sway the other person or if really necessary, find an arbiter such as the project lead, who exists expressly for this purpose. We all (hopefully) want to make meson better, but the corollary to this is that sometimes the other person believes he is making meson better by being a pedant about the design and UX.

Instead of even offering a fig leaf towards building consensus, you self-merged a MAJOR new feature on your call alone and over objections, apparently under the belief that having a merge bit means that you are allowed to do anything you want whatsoever in a kind of Chaotic Evil free-for-all.

I object to this and I reverted that PR for being dishonestly merged and I will do it a hundred times again if I need to, which I probably will need to because this is the tail end of a long time pattern. I have no qualms about doing it -- on the contrary it is my ethical duty to do it.

I find it hugely offensive in the extreme that your reaction to this is to make it about "Eli versus other people" simply because I'm the person who you picked a fight with, and then libelously claim that I'm simply deleting features I don't personally like (and for a feature that you self-merged because it's a feature YOU personally like).

Presumably now once again you'll go on a long rant about how Meson is a terrible project and you hate working on meson "because things take too long to merge and everything becomes some long drawn out discussion", which is still, every time you complain about it, just another way of saying "I'm mad that working on a project with other developers means I have to respect their opinions".

Please. Work within the system using the documented consensus-building system, rather than against it. You are egregiously wasting everyone's time here -- and if you don't care about anyone else's time, that still includes your own.

[bonzini]

Please rebase on top of #15133 then

That's exactly where I started from, because the new base class could provide a simple type for all programs (like @dcbaker wanted) without needing a type alias. Since you said you weren't working on it, I didn't feel compelled to keep your commits as the base, especially when there were bugfixes involved as is the case for cmd_array() or full_path().