Visual C++ 2008

[chrisjones]

hi

I just downloaded POCO as we (the open game engine project) are thinking of moving away from boost. I need to build it with visual C++ 2008 but am having problems. i upgraded the vc80 projects but building just gives this error:

^Performing Custom Build Step
'mc' is not recognized as an internal or external command,
operable program or batch file.
Project : error PRJ0019: A tool returned an error code from "Performing Custom Build Step"^

and from the build log, this is the command thats running/failing

mc -h e:GameDevlibrariespoco-1.3.2Foundationsrc -r e:GameDevlibrariespoco-1.3.2Foundationsrc e:GameDevlibrariespoco-1.3.2Foundationsrcpocomsg.mc

does anyone know how to fix this? i did search around a bit but i could of missed it.

thanks
Chris

[guenter]

Hi Chris,

you could try the source code from the Subversion trunk, which has VC++ 2008 project files. I am still with VC++ 2005, so I can't offer much help here.

[chrisjones]

thanks for your quick reply.

i downloaded from SVN, although as i havent used it much, i ended up downloading every single branch and 3 different trunks.

anyway, i still get the same error. Should there be anything i need to do, other than downloading POCO and clicking build in visual studio? i did look at the tutorial, but i didnt see anything except setting some paths in the PATH environment variable, which ive tried.

Chris

[alex]

> thanks for your quick reply.
>
> i downloaded from SVN, although as i havent used it much, i ended up downloading every single branch and 3 different trunks.
>
> anyway, i still get the same error. Should there be anything i need to do, other than downloading POCO and clicking build in visual studio? i did look at the tutorial, but i didnt see anything except setting some paths in the PATH environment variable, which ive tried.

Those solution files were added recently by Eran, so he would probably be the person to ask. I believe he follows this forum, but you may also try the mailing list.

In the meantime, are you using the full commercial or the free VS 2008 Express?

The normal behavior is that POCO builds out-of-the-box on all supported platforms.

Alex

[bird]

> ^Performing Custom Build Step
> 'mc' is not recognized as an internal or external command,
> operable program or batch file.
> Project : error PRJ0019: A tool returned an error code from "Performing Custom Build Step"^

Sorry, I can't help much but I did hit the same problem when trying to compile Foundation as a static library yesterday. I'm using VC++ Express 2005 and have never had any problems building Poco before. I ended up starting from scratch with a fresh SVN grab and didn't get the error message next time around, so I have no idea what the problem really was.

-Steve

[alex]

> Sorry, I can't help much but I did hit the same problem when trying to compile Foundation as a static library yesterday. I'm using VC++ Express 2005 and have never had any problems building Poco before. I ended up starting from scratch with a fresh SVN grab and didn't get the error message next time around, so I have no idea what the problem really was.

I'm not sure whether and how that would do it, but I have removed pocomsg.h and MSG00001.bin from the repository yesterday. The fact that they were present but created by a different VS version could have caused you to first have the problem and then later not. I'm also not sure whether that explains the original poster's problem.

Here's the log from my yesterday's commit:

Code: Select all


Revision: 452
         http://poco.svn.sourceforge.net/poco/?rev=452&view=rev
Author:   aleksf
Date:     2008-02-02 13:55:14 -0800 (Sat, 02 Feb 2008)

Log Message:
-----------
DynamicAny:operator [] fix (did not compile w/ VS 2003)

Modified Paths:
--------------
   poco/trunk/Foundation/include/Poco/DynamicAny.h
   poco/trunk/Foundation/src/DynamicAny.cpp
   poco/trunk/Foundation/testsuite/src/DynamicAnyTest.h

Removed Paths:
-------------
   poco/trunk/Foundation/src/MSG00001.bin
   poco/trunk/Foundation/src/pocomsg.h



Alex

[chrisjones]

I deleted poco and downloaded it again, this time only getting the trunk. I made sure those files arent there, but built it, but i still get the same error.

Chris

[chrisjones]

> Sorry, I can't help much but I did hit the same problem when trying to compile Foundation as a static library yesterday. I'm using VC++ Express 2005 and have never had any problems building Poco before. I ended up starting from scratch with a fresh SVN grab and didn't get the error message next time around, so I have no idea what the problem really was.

thanks, as i wrote in my previous post, ive downloaded the trunk from SVN, i also just tried to build the Foundation using each of the configurations, but i got the same error on all 4.

[alex]

> I deleted poco and downloaded it again, this time only getting the trunk. I made sure those files arent there, but built it, but i still get the same error.

I'll look into this problem. You may also want to check and see if any of these apply to your problem.

Alex

[chrisjones]

> I'll look into this problem. You may also want to check and see if any of these apply to your problem.

thanks, looking at that link, it looks like problem #5 might be the same

^Problem #5: Exception in ResourceCompiler.exe

ResourceCompiler.exe is a managed application that we wrote to automatically create C# string resources and matching C++ resources (with matching header files) for cross project message availability. Very nice. And very broken. As with many internal tools, the error handling sucks, but it was easy to see from the exception that one of the required input files was missing. Backtracing this, it turns out that the SDK tools "MC.exe" (Message Compiler) and "RC.exe" (Resource Compiler) were supposed to run and spit out some stuff. The problem is that (you guessed it) the locations for these utilities have changed with VS2008 and the batch file which calls them was silently skipping those steps. Double doh!

Now I'm on the crux of indecision. The "pure" way to solve this problem without affecting anything in source control is just to copy these (and other related) files from their new location in the v6.0Ain SDK folder (which we already mapped to [app]VCPlatformSDK) to the old location (which was [app]Common7in). The "correct" way to solve this problem is to fix the stupid batch file to test for the existence of mc.exe and rc.exe and if they don't exist, try the other folder. If if they don't exist there, fail the build where the actual problem occurred rather than letting it continue and fail obscurely somewhere else. ^

i dont know if it is related, ill have a go at fixing it though.
Chris