I don't think this quite works as there are other variations not
captured here. Rather than "zipped" it should just be "external".
Whether the debuginfo files are zipped or not is then an additional
build time option. Additionally we still have to be able to control
the degree of stripping that is carried out. It doesn't make sense to
me to try and enumerate all possible combinations as top-level
configure options.
Further, as Dan was saying, this doesn't capture the overlap between
"internal" and "external" because we still leave some symbols internal
even when creating the debuginfo file.
So I don't think this proposed categorization works. We still have
three aspects:
- generating symbols into the object files
- stripping symbols from the final binaries
- saving symbols into an external form
Each of which can potentally be varied (of course if you don't
generate symbols in the obj files stripping and saving are non issues).
But they are not independent on each other!
Unless you generate debug symbols, you can't strip them, nor save them
elsewhere. So generating debug symbols (your item #1) is a prerequisite
for the rest of your items.
And while, technically, you can save symbols externally, and at the same
time keep them in the binary, that does not make sense. So, in a
practical sense, you are going to do #2 if you are going to do #3.
And you can't zip external symbols unless you create a non-zipped
version. And if you zip them, it does not make sense to keep the
non-zipped version.
And yes, we do not strip all debug information when creating external
debug info. But there seems to be no real use case (not even for
IcedTea, as it turned out) to want a completely stripped binary, I don't
think that's worth discussing much. That's just part of how the external
debuginfo scheme works.
Can you give a more concrete example of the variations of your "aspects"
that you think my suggested solution would not capture?
/Magnus
