Boost logo

Boost-Build :

From: Reece Dunn (msclrhd_at_[hidden])
Date: 2005-10-16 08:56:08

Alexey Pakhunov wrote:
> Reece Dunn wrote:
>>>import "../core/core.idl";
>>Yes. I am importing them relatively like the above.
> It is a problem of midl.exe itself. It does not handle relative paths
> when importing.


>>I suppose I could try adding an <include> to the project:
>> myproject/Jamfile
>> project myproject : : requirements <include>. ;
> It will work but only if you apply one more fix:
> RCS file: /cvsroot/boost/boost/tools/build/v2/tools/common.jam,v
> [snip]
> midl.exe does not recognize '-I"..."' but recognizes '"-I..."'. :(

Great :). This also fixes an issue using your MIDL patch with my
no-vcvars support when using response files.

>>More comments will follow when I have had a chance to review the patch.
> Cool! I'm looking forward to it.

Here are some more comments on the patch:

[1] 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?

I would be happy with typelib as a name, or (to be consistent with exe
and lib, tlb). I am not sure whether CORBA produces type libraries, so
would another name be better? Note that I am not sure what this name
would be.

[2] I am getting the following error:

midl : command line error MIDL1000 : missing source-file name

midl /nologo /Oicf /robust /win32 /tlb

&& del /f

This is because:

$(.IDL) /nologo /U$(UNDEFS) $(MIDLFLAGS) /tlb "$(<[1]:W)" /h
"$(<[2]:W)" /iid "$(<[3]:W)" /proxy "$(<[4]:W)" /dlldata "$(<[5]: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.

[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:

#include "stdafx.h"

#include "myidl.h"

so myidl will be built after mycomobj!

[4] With the fix for issue [2] my IDL file builds fine. However, I have

feature character-set : narrow wide mbcs : composite ;
feature windows
: none
95 98 me
nt 2k xp 2k3 vista
pocketpc2003 smartphone2003
: propagated composite ;

which is causing problems, for given:

mstypelib ReaderCore : ReaderCore.idl ;

lib Reader.Core
main.cpp ...

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 :(.

[5] When rebuiling the project, I am getting:

midl : command line error MIDL1020 : cannot open response file
Could Not Find

- Reece


Boost-Build list run by bdawes at, david.abrahams at, gregod at, cpdaniel at, john at