Re: [BBv2] Patch, review needed - support of Microsoft .idl files for MSVC

From: Reece Dunn (msclrhd_at_[hidden])
Date: 2005-10-18 02:48:35

Alexey Pakhunov wrote:
> Reece Dunn wrote:
>>[1] The change to
>> type.register MSTYPELIB : tlb : H ;
>>
>>This suggests that IDL are MS-specific targets. There are other IDL 
>>compilers - the Mozilla one; the WINE one; CORBA compilers and so on. 
>>Thus, mstypelib is too specific. Is there any reason for the change?
> 
> The reason is to make it so specific. :-) The rule 'mstypelib' converts
> Microsoft IDL into Microsoft type library. Other IDL compilers will use
> own rules that will make similar conversions. For instance 'xptypelibe'
> will convert an XPIDL file (.idl) into XPConnect type library (.xpt).
> 
> This is also the way to resolve the ambiguity when that same extension
> .idl means can be used by different IDL dialects.

I understand now. Thanks for the clarification.

>>[2] I am getting the following error:
>>This is because:
>>
>> $(.IDL) /nologo /U$(UNDEFS) $(MIDLFLAGS) ...
>>
>>doesn't specify the IDL file.
> 
> The IDL file is specified by the response file. It should not be present
> in the command line. I remember Vladimir told that there is a problem
> with tracking dependencies on response files - BB does not regenerate
> response file correctly if the way .jam has been changed. Try to delete
> all 'bin' directories and build again.

That works. This problem was occuring because of the response file 
problem :(.

We really need to fix the response file regeneration issues. I am 
looking into this, but haven't had the time to look at it in detail as 
it isn't a simple fix.

>>[3] This is more a BBv2/bjam issue: when scanning for dependencies, it 
>>only scans one level deep, so doesn't pick up things like:
>>
>>mycomobj.cpp
>> #include "stdafx.h"
>>
>>stdafx.h
>> #include "myidl.h"
>>
>>so myidl will be built after mycomobj!
> 
> "myidl.h" is a generated header, right? Vladimir should look at this issue.

That's right. It is generated by myidl.h. I can work around this issue 
for now, but other people would experience this, especially when 
precompiled headers are in place.

>>[4] With the fix for issue [2] my IDL file builds fine. However, I have
> [snip]
>>When building Reader.Core, it complains about being able to find 
>>ReaderCore.h. This is because the layout is:
>>
>> release/character-set-wide/ReaderCore.h
>> release/character-set-wide/windows-nt/ReaderCore.h
>>
>>This is because Reader.Core has <windows>nt, but ReaderCore doesn't. 
>>This suggests it isn't pulling in the include directory for ReaderCore 
>>like the initial version :(.
> 
> Give me some time to play with it.

Thanks :).

>>[5] When rebuiling the project, I am getting:
>>
>>midl : command line error MIDL1020 : cannot open response file 
>>...\..\..\build\tools\speaker\reader\html\msvc-7.1\release\character-set-wide\ReaderHTML.tlb.rsp 
>>Could Not Find 
>>F:\devel\build\tools\speaker\reader\html\msvc-7.1\release\character-set-wide\ReaderHTML.tlb.rsp
> 
> I check this one too.

Great :).

- Reece