Re: [Qemu-devel] [PATCH v3 3/4] qemu-ga: Created a separate component for each installed file in the MSI

[Leonid Bloch]

Thanks for pointing that out, Michael!

This indeed happens when configure is called out of tree.
But this bug was not introduced with this series of patches, so it is
irrelevant here.
We will issue another patch to address it shortly.

Thanks again,
Leonid.

On Wed, Aug 26, 2015 at 12:48 AM, Michael Roth
<address@hidden> wrote:
> Quoting Leonid Bloch (2015-08-03 12:54:23)
>> This is done to follow the recommendations given here: 
>> https://msdn.microsoft.com/en-us/library/aa368269%28VS.85%29.aspx
>>
>> Signed-off-by: Leonid Bloch <address@hidden>
>> ---
>>  qga/installer/qemu-ga.wxs | 47 
>> ++++++++++++++++++++++++++++++++++++-----------
>>  1 file changed, 36 insertions(+), 11 deletions(-)
>>
>> diff --git a/qga/installer/qemu-ga.wxs b/qga/installer/qemu-ga.wxs
>> index dac1df0..2302745 100644
>> --- a/qga/installer/qemu-ga.wxs
>> +++ b/qga/installer/qemu-ga.wxs
>> @@ -71,16 +71,6 @@
>>          <Directory Id="qemu_ga_directory" Name="Qemu-ga">
>>            <Component Id="qemu_ga" 
>> Guid="{908B7199-DE2A-4DC6-A8D0-27A5AE444FEA}">
>>              <File Id="qemu_ga.exe" Name="qemu-ga.exe" 
>> Source="../../qemu-ga.exe" KeyPath="yes" DiskId="1"/>
>> -            <?ifdef var.InstallVss ?>
>> -            <File Id="qga_vss.dll" Name="qga-vss.dll" 
>> Source="../vss-win32/qga-vss.dll" KeyPath="no" DiskId="1"/>
>> -            <File Id="qga_vss.tlb" Name="qga-vss.tlb" 
>> Source="../vss-win32/qga-vss.tlb" KeyPath="no" DiskId="1"/>
>> -            <?endif?>
>> -            <File Id="iconv.dll" Name="iconv.dll" 
>> Source="$(var.Mingw_bin)/iconv.dll" KeyPath="no" DiskId="1"/>
>> -            <File Id="libgcc_arch_lib" Name="$(var.ArchLib)" 
>> Source="$(var.Mingw_bin)/$(var.ArchLib)" KeyPath="no" DiskId="1"/>
>> -            <File Id="libglib_2.0_0.dll" Name="libglib-2.0-0.dll" 
>> Source="$(var.Mingw_bin)/libglib-2.0-0.dll" KeyPath="no" DiskId="1"/>
>> -            <File Id="libintl_8.dll" Name="libintl-8.dll" 
>> Source="$(var.Mingw_bin)/libintl-8.dll" KeyPath="no" DiskId="1"/>
>> -            <File Id="libssp_0.dll" Name="libssp-0.dll" 
>> Source="$(var.Mingw_bin)/libssp-0.dll" KeyPath="no" DiskId="1"/>
>> -            <File Id="libwinpthread_1.dll" Name="libwinpthread-1.dll" 
>> Source="$(var.Mingw_bin)/libwinpthread-1.dll" KeyPath="no" DiskId="1"/>
>>              <ServiceInstall
>>                Id="ServiceInstaller"
>>                Type="ownProcess"
>> @@ -97,7 +87,32 @@
>>              </ServiceInstall>
>>              <ServiceControl Id="StartService" Start="install" Stop="both" 
>> Remove="uninstall" Name="QEMU-GA" Wait="no" />
>>            </Component>
>> -
>> +          <?ifdef var.InstallVss?>
>> +          <Component Id="qga_vss_dll" 
>> Guid="{CB19C453-FABB-4BB1-ABAB-6B74F687BFBB}">
>> +            <File Id="qga_vss.dll" Name="qga-vss.dll" 
>> Source="../vss-win32/qga-vss.dll" KeyPath="yes" DiskId="1"/>
>
> Is there a reason these paths are seemingly relative to
> qga/installer/qemu-ga.wxs? I'd imagine that works for running wixl
> command within that directly, but top-level Makefile 'msi' ends up
> bombing if I do 'make msi':
>
> address@hidden qemu-build-w64]$ ../w/qemu4.git/configure 
> --cross-prefix=x86_64-w64-mingw32- \
>   --with-vss-sdk=/home/mdroth/w/vss-win32/ --target-list=x86_64-softmmu
>   --extra-cflags=-Wall --enable-guest-agent --enable-guest-agent-msi
> ...
>
> address@hidden qemu-build-w64]$ make -j4 qemu
> ...
>   CC    trace/generated-events.o
>   AR    libqemustub.a
>   CC    qemu-img.o
>   CC    qmp-marshal.o
>   AR    libqemuutil.a
>   LINK  qemu-ga.exe
>   LINK  qemu-img.exe
>   LINK  qemu-io.exe
> ...
>
> address@hidden qemu-build-w64]$ make msi
>      LEX convert-dtsv0-lexer.lex.c
> make[1]: flex: Command not found
>      BISON dtc-parser.tab.c
> make[1]: bison: Command not found
>      LEX dtc-lexer.lex.c
> make[1]: flex: Command not found
>   WIXL  qemu-ga-x86_64.msi
> Couldn't find file ../../qemu-ga.exe
> make: *** [qemu-ga-x86_64.msi] Error 1
>
> The fix seems simple enough, but I want to make sure I'm not doing something
> stupid and have some idea of how people are using the current MSI installer
> code.
>