From: Reece Dunn (msclrhd_at_[hidden])
Date: 2005-10-18 02:48:35
Alexey Pakhunov wrote:
> Reece Dunn wrote:
>> 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.
>> 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
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.
>> This is more a BBv2/bjam issue: when scanning for dependencies, it
>>only scans one level deep, so doesn't pick up things like:
>> #include "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.
>> With the fix for issue  my IDL file builds fine. However, I have
>>When building Reader.Core, it complains about being able to find
>>ReaderCore.h. This is because the layout is:
>>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.
>> When rebuiling the project, I am getting:
>>midl : command line error MIDL1020 : cannot open response file
>>Could Not Find
> I check this one too.
Boost-Build list run by bdawes at acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk