MantisBT - CMake
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0012909CMakeCMakepublic2012-01-23 14:482016-06-10 14:31
ReporterJames Mansion 
Assigned ToKitware Robot 
PriorityhighSeveritymajorReproducibilityalways
StatusclosedResolutionmoved 
PlatformWindowsOSWindowsOS Version7
Product VersionCMake 2.8.6 
Target VersionFixed in Version 
Summary0012909: rc.exe cannot find generated type library, Visual Studio 10 builder
DescriptionI have an IDL file that generates a type library, and an RC file that wants to embed it.

The .tlb is emitted here:

C:\build\easyrtd.vs10\EasyRTD\easyrtd.dir\Debug>dir *.tlb
 Volume in drive C has no label.
 Volume Serial Number is 5AB0-0B44

 Directory of C:\build\easyrtd.vs10\EasyRTD\easyrtd.dir\Debug

23/01/2012 18:52 2,612 EasyRTD.tlb
               1 File(s) 2,612 bytes
               0 Dir(s) 171,651,473,408 bytes free

there is no obvious sign of the rc file (easyrtd.rc) in the working build directory, but if I insert a #error statement I get:

1>C:\src\easyrtd\EasyRTD\easyrtd.src\EasyRTD.rc(21): error RC2188: C:\build\easyrtd.vs10\EasyRTD\EasyRTD.dir\Debug\RCa03492(25) : fatal error RC1116: RC terminating after preprocessor errors
1>

which suggests that the file was copied over, if temporarily.

Unfortunately I cannot say:

2 TYPELIB "EasyRTD.tlb"

since rc.exe fails to find the file.

I can say:

2 TYPELIB "c:\build\easyrtd.vs10\EasyRTD\easyrtd.dir\Debug\EasyRTD.tlb"

or, I can say:

2 TYPELIB "EasyRTD.tlb"

if I also (don't laugh!) say in CMakeLists.txt:

include_directories(. c:/build/easyrtd.vs10/EasyRTD/easyrtd.dir/Debug)

before the source definition.


Steps To ReproduceSimple project that defines a type library and tries to embed it should do.
Additional InformationIts concerning also that there isn't a failure from include scanning I guess.

Is this construct (generate and import a type library) supported at all at the moment?

Is there a preferred recipe?
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
2012-01-23 14:48James MansionNew Issue
2012-01-23 14:54David ColeNote Added: 0028394
2012-01-23 16:35James MansionNote Added: 0028395
2012-01-23 18:02James MansionNote Added: 0028396
2012-08-11 21:09David ColeStatusnew => backlog
2012-08-11 21:09David ColeNote Added: 0030354
2016-06-10 14:28Kitware RobotNote Added: 0041970
2016-06-10 14:28Kitware RobotStatusbacklog => resolved
2016-06-10 14:28Kitware RobotResolutionopen => moved
2016-06-10 14:28Kitware RobotAssigned To => Kitware Robot
2016-06-10 14:31Kitware RobotStatusresolved => closed

Notes
(0028394)
David Cole   
2012-01-23 14:54   
Don't know if you'd call it a recipe or not, but we do have a test in our test suite that builds an idl file.

Check out the source tree for the "CMake/Tests/VSMidl" test:

  http://cmake.org/gitweb?p=cmake.git;a=tree;f=Tests/VSMidl;h=f86fb65a6ba2fd8b3087377520aeb00a8c4337ad;hb=7f8f6dbf45aa5250281c7e383e3d32599590564b [^]
(0028395)
James Mansion   
2012-01-23 16:35   
Seems that:

include_directories(. "${CMAKE_CURRENT_BINARY_DIR}/\$(IntDir)")

does the trick. It does seem unfortunate that this is needed though, given that we otherwise have a reasonable facsimile of what happens with a 'normal' build finding files relative to the includer.
(0028396)
James Mansion   
2012-01-23 18:02   
While that works for VS10, it doesn't seem to work for nmake.

Generating for nmake and attempting a build sees rc.exe invoked before midl, and predictably EasyRTD.tlb is not found.

I'm guessing that there is no modelling of EasyRTD.tlb as an output of midl nor that it is a dependent input of rc.
(0030354)
David Cole   
2012-08-11 21:09   
Sending old, never assigned issues to the backlog.

(The age of the bug, plus the fact that it's never been assigned to anyone means that nobody is actively working on it...)

If an issue you care about is sent to the backlog when you feel it should have been addressed in a different manner, please bring it up on the CMake mailing list for discussion. Sign up for the mailing list here, if you're not already on it: http://www.cmake.org/mailman/listinfo/cmake [^]

It's easy to re-activate a bug here if you can find a CMake developer who has the bandwidth to take it on, and ferry a fix through to our 'next' branch for dashboard testing.
(0041970)
Kitware Robot   
2016-06-10 14:28   
Resolving issue as `moved`.

This issue tracker is no longer used. Further discussion of this issue may take place in the current CMake Issues page linked in the banner at the top of this page.