From: Alexey Pakhunov (alexeypa_at_[hidden])
Date: 2005-10-17 12:32:12
Reece Dunn wrote:
>  The change to
> type.register MSTYPELIB : tlb : H ;
> means that
> tlb myidl : myidl.idl ;
> mstypelib myidl : myidl.idl ;
> 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 am getting the following error:
> This is because:
> $(.IDL) /nologo /U$(UNDEFS) $(MIDLFLAGS) /tlb "$(<:W)" /h
> "$(<:W)" /iid "$(<:W)" /proxy "$(<:W)" /dlldata "$(<:W)"
> @"$(RSP:W)" && $(RM) "$(RSP)"
> doesn't specify the IDL file. The fix is:
> $(.IDL) /nologo /U$(UNDEFS) $(MIDLFLAGS) "$(>:W)" ...
> This was present in your previous version, so I think you just missed
> it when building the patch.
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.
>  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.
>  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.
Best regards/Venlig hilsen,
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