On Tue, Jan 14, 2025 at 05:17:28PM +0000, Alexandru Elisei wrote:
...
> > > +# $arch will have changed when cross-compiling.
> > > +[ -z "$processor" ] && processor=$(get_default_processor $arch)
> >
> > The fact that $arch and $processor are wrong until they've had a chance to
>
> $processor is never wrong. $processor is unset until either the user sets it
> with --processor, or until this line. This patch introduces $default_processor
> only for the purpose of having an accurate help text, it doesn't change when and
> how $processor is assigned.
I should have said "The fact that $arch and $default_processor are wrong..."
>
> > be converted might be another reason for the $do_help idea. But it'll
> > always be fragile since another change that does some sort of conversion
> > could end up getting added after the '[ $do_help ] && usage' someday.
>
> configure needs to distinguish between:
>
> 1. The user not having specified --processor when doing ./configure.
> 2. The user having set --processor.
>
> If 1, then kvm-unit-tests can use the default $processor value for $arch,
> which could have also been specified by the user.
>
> If 2, then kvm-unit-tests should not touch $processor because that's what the
> user wants.
>
> Do you see something wrong with that reasoning?
If we output $default_processor in usage() before it's had a chance to be
set correctly based on a given cross arch, then it won't display the
correct name.
>
> Also, I don't understand why you say it's fragile, since configure doesn't
I wrote "it'll always be fragile" where 'it' refers to the most recent
object of my paragraph ("the $do_help idea"). But, TBH, I'm not sure
how important it is to get the help text accurate, so we can just not
care if we call usage() with the wrong strings sometimes.
Thanks,
drew
> touch $processor until this point (and unless the user sets it, of course).
>
> Thanks,
> Alex
>
> --
> kvm-riscv mailing list
> kvm-riscv@xxxxxxxxxxxxxxxxxxx
> http://lists.infradead.org/mailman/listinfo/kvm-riscv
