On 15/09/20 16:27, Richard Henderson wrote:
> On 9/14/20 11:27 PM, Paolo Bonzini wrote:
>> Looks good. Can you just add a "# Submodules" heading above the test?
>>
>> I would also like to remove the "yes" value (that is, the default fails if
>> the
>> internal copy is not there) but it can be done later for all submodules.
>
> Unless you simply plan to rename {no, yes} to {disabled, enabled}, as for the
> Feature objects, why?
>
> That seems to be the only sensible value for --enable-foo, without the =system
> or =git specifiers. We *should* fail if no system library nor internal copy
> is
> present.
Yes, that was a bit concise. I would like "auto" to take the meaning
that "yes" currently as. Right now we have
no -> Easy :)
system -> System capstone if found, fail otherwise
internal/git -> Compile capstone if found, fail otherwise
auto -> System capstone, then internal, then disable
yes -> System capstone, then internal, then fail
I'm not sure of the usefulness of disabling a dependency because we
don't have it checked out, since we have the machinery to do the
checkout automatically. So that would become:
no -> Easy :)
system -> System capstone if found, fail otherwise
internal/git -> Compile capstone if found, fail otherwise
auto -> System capstone, then internal, then fail
The disadvantage is that it would be different from other "auto"
symbols, which never fail. But then those other "auto" symbols do not
have a built-in fallback, so the question is whether the combination of
1) building from a fresh git checkout
2) --disable-git-update
3) not having a system capstone/libfdt/slirp
4) not having --disable-{capstone,libfdt,slirp} on the command line
is more likely to be intentional or operator error.
Paolo
