11.06.2013 01:45, Peter Maydell wrote: > On 10 June 2013 21:47, Michael Tokarev <m...@tls.msk.ru> wrote: >> Or else >> >> ./configure --disable-system --enable-virtfs >> >> (which makes no sense by its own but does not error out) >> will fail to build, because it will define CONFIG_VIRTFS, >> and the makefile will try to build virtfs-proxy-helper >> manpage (but not the executable). >> >> Cc: qemu-triv...@nongnu.org >> Cc: M. Mohan Kumar <mo...@in.ibm.com> >> Signed-off-by: Michael Tokarev <m...@tls.msk.ru> >> --- >> configure | 2 ++ >> 1 file changed, 2 insertions(+) >> >> diff --git a/configure b/configure >> index a3f0b7a..0ff0380 100755 >> --- a/configure >> +++ b/configure >> @@ -3423,6 +3423,8 @@ if test "$softmmu" = yes ; then >> tools="qemu-ga\$(EXESUF) $tools" >> fi >> fi >> +else >> + virtfs=no >> fi > > This doesn't feel to me like it's quite the right way > to fix this bug. The current code in configure seems > to tangle up (a) was virtfs requested and can we do it? > with (b) what do we need to do if it was? (build some > extra tools) and (c) when does it make sense? not for > linux-user targets. So you end up with an 'else virtfs=no' > clause added in an odd place. If the mess was untangled > then this probably wouldn't be necessary.
Um. I don't think that tangling is a bad thing really. Having different variables or options for it will be too bloated, in my opinion. I don't think there should be anything done with it. How about something like this: --- a/configure +++ b/configure @@ -3810,7 +3810,7 @@ fi if test "$libattr" = "yes" ; then echo "CONFIG_LIBATTR=y" >> $config_host_mak fi -if test "$virtfs" = "yes" ; then +if test "$virtfs" = "yes" && test "$target_softmmu" = "yes" ; then echo "CONFIG_VIRTFS=y" >> $config_host_mak fi if test "$vhost_scsi" = "yes" ; then (BTW, why configure uses this "test" instead of more readable [ ] ? ) > Also, disabling building tools and docs in general seems > broken: --disable-tools disables building qemu-img, for > instance, but not its documentation. So maybe we should > fix this by generally making sure we don't build the docs > unless we build the tool as well. This has been addressed by a separate patch sent by afaerber. Thanks, /mjt