One is what you describe - a generic utility supporting everything that gets installed into say /usr/local/bin for lots of different invocations to do lots of different things with lots of different coreboot images.
Two is specifically what is required to complete the configured build.
It's certainly useful, and I argue highly desirable, to consider these two cases distinct.
Yes, those are different cases and they could use differently configured builds of cbfstool. Whether that's desirable is a different question. Adding a configuration system to cbfstool would come with a lot of maintenance overhead -- rather than just making sure the tool as a whole keeps working, we'd have to ensure all possible configurations keep working independently. The way cbfstool is currently written doesn't really lend itself to easily split out all these kinds of optional things. You're asking for a lot of work, basically, and I fail to see the benefit on the other side. The current monolithic design shouldn't really cause problems or drawbacks to anyone (and quite frankly, I think it doesn't -- as mentioned before I think the issues discussed in this thread don't really have much to do with how big cbfstool is, and it doesn't really seem like a good "solution" to the HOSTCC problem to just allow switches to stop building parts that happened to cause compiler problems in this specific instance. Sooner or later some compiler-specific code would be added to a core function that you can't configure out).
Even worse is that you find it acceptable, or desirable, that a submodule is silently pulled in during the build. That may be typical for web development, but nothing that should be proliferated.
Yeah, I really don't understand your concern here. Is there maybe some confusion about how Git submodules work? You seem to imply that this may cause some kind of security or availability problem where there is none: submodule code is mirrored on and downloaded from coreboot.org, same as the main repository. The currently active submodule repository HEAD is stored in the main coreboot repository (as a Git SHA), so you will always get exactly the version of the code you're supposed to have, and updating that is a step that is manually committed to the main coreboot repository. Submodules cannot suddenly become unavailable or taken over by malicious actors due to actions outside coreboot.org's control -- Git is not node.js. If you're just someone building code from source in your local checkout, it really makes zero practical difference to you whether that code comes out of the main coreboot repository or a submodule (both of them are already on your disk as part of the checkout and cryptographically guaranteed by coreboot.org, nobody else).
Really, your host system's local glibc (which is also linked into cbfstool) is a lot more unpredictable and potentially problematic here than the parts of vboot that it includes.
I am just saying I don't think this discussion should be about vboot
It is because that's what consistently causes me extra work and frustration every time I want to build a minimal coreboot.
Well then let's please talk about those specific frustrations and try to find practical solutions instead. Like I said earlier, we're really not trying to make vboot annoying (or even visible) to those who don't want to deal with it, and I'm convinced that it shouldn't be. The submodule setup we have right now really works very well in general and there's basically no difference for you in whether something is built out of coreboot/src or coreboot/3rdparty/xxx. If it does cause friction for you, let me know and I'll try my best to help solve that. I understand that there's the HOSTCC issue, but as I said it really doesn't have anything to do with vboot, and there's nothing vboot alone could do to solve it, nor would somehow removing vboot really solve anything about that.
FWIW I do seem to recall that this already came up back when __attribute__((fallthrough)) was added to vboot, and back then everyone seemed to agree that it was reasonable to assume the same version for the host compiler that we use in crossgcc. If we now changed our mind and think this keeps causing too much pain to people all the time, I'm happy to take that back out of vboot and make it compatible with whatever older version you care about if that would alleviate people's concerns. We're perfectly willing to fully align vboot's code base on whatever the coreboot policy is on these sort of things, the problem is just that coreboot can't seem to decide on a clear policy for the host compiler, and whenever this is brought back up again somehow vboot always gets all the blame.