Carbide 1.2 does not copy header files

[KarstenBln]

I just have upgraded to Carbide.C++ 1.2. After having used 1.0 and 1.1 before. Now I wanted to import an existing projectwhich consists of a few subproject.. There is no way in 1.2 to import it by selecting the mmp files. There is one main bld.inf file that can be selected and imports the whole project. That seemed to work successfully but compilation failed.
The reason: No header file (.h) has been copied from the project folder to the SDK's include folder. Using the older versions of Carbide and using .mmp file import the header files are copied.
The bld.inf is located in <project's root>\group
and looks like:

PRJ_PLATFORMS

PRJ_MMPFILES

//gnumakefile ..\gui30\group\icons_scalable.mk

..\sipengine\group\SIPEngine.mmp
..\socketengine\group\SocketEngine.mmp
..\CommunicationChannel\group\CommunicationChannel.mmp
..\ImClientEngine\group\imclientengine.mmp
..\gui\group\imclient.mmp
..\ImClientEComPlugin\group\ImClientEComPlugin.mmp

Is this a bug in carbide.c++ ? I remember that we had the same problem with Carbide 1.1 and for this reason we chose to use the .mmp files although it was not as comfortable because we had to import every single subproject one by one.

[timm-ah]

See the PRJ_EXPORTS bld.inf command. Or easier, open the bld.inf file in the bld.inf editor and choose the Exports tab and click "Add" under the "Exports" section.

Tim

[KarstenBln]

Hello Tim,

I just got to look ...
Well, I have found the editor. All 6 subprojects are listed in the components tab page. On the export page there are two lists but both are empty. It seems by clicking "add" I have to enter the path to each header file manually what would be even more uncomfortable than importing all single subprojects by mmp files in Carbide 1.1.

Does the "PRJ_EXPORTS bld.inf command" refer to command line compiling or where can I find info about it?

Sorry, I'm still beginner and not really familiar with the Carbide or Eclipse IDE.

Thank you,
Karsten

[timm-ah]

Hi - Here's a reference:

<http://www.symbian.com/Developer/techlib/v70sdocs/doc_source/ToolsAndUtilities/Build-ref/bldmake-ref/prj_exports.html>

The prj_exports just refers to the exports build command, found here:

<http://www.symbian.com/Developer/techlib/v70sdocs/doc_source/ToolsAndUtilities/Build-ref/abld-syntax-ref/export.html#abld%2dsyntax%2dref5>

May not be the correct OS version but the docs should still be the same.

Tim

[KarstenBln]

Hi - Here's a reference:

<a href="http://www.symbian.com/Developer/techlib/v70sdocs/doc_source/ToolsAndUtilities/Build-ref/bldmake-ref/prj_exports.html">Link</a>

The prj_exports just refers to the exports build command, found here:

<a href="http://www.symbian.com/Developer/techlib/v70sdocs/doc_source/ToolsAndUtilities/Build-ref/abld-syntax-ref/export.html#abld%2dsyntax%2dref5">Link</a>

May not be the correct OS version but the docs should still be the same.

Tim

Hello Tim,
thanks for the help. I have understood that PRJ_EXPORTS is a section inside the bld.inf file. (Though the links were invisible because enclosed in &lt;&gt; and that was invalid html code for a browser.)

It seems from the syntax description the main bld.inf file cannot contain references to each bld.inf of a subproject. The subproject's bld.inf files do contain the export sections. So I guess I have to copy all export sections from the single bld.inf files to the main one (and adjust the paths, of course).
Or like our last approach import every single subproject using their bld.inf files instead of the .mmp files.

Karsten

[timm-ah]

Thanks, I didn't know that about PRJ_EXPORTS. Sounds like you have a couple of workarounds though. And thanks for fixing those links.

Tim

[pzul_wisner]

I just noticed that my Carbide C++ 1.2 build was copying my header file into the SDK's include folder. It seems that Carbide C++ has covertly inserted PRJ_EXPORTS into my bld.inf file.

Isn't modifying the SDK a bad idea? Seems like it will lead to a lot of problems where bugs are hidden because the developer is looking at the wrong copy of a header file. Or problems where another developer can't reproduce a result. Isn't there also a risk of over-writing Symbian or S60 SDK headers?

-Paul