Recognizer .mdl in Carbide.c++

[BlueLava]

Hi,

I can't get the code in the RecogEx example to compile in Carbide.c++. I receive the following errors:

No rule to make target '../RecogEx.cpp', needed by 'RecogEx.o'.

This line:

_LIT8(KDummyMimeType,"text/dum");

also produces an error:

Syntax error encountered in file ..... RecogEx.cpp on line 12.

Does anyone know what I need to do to get this working?

Thanks!

[mpinsonneault]

What SDK are you using to build this application?

Regards,

Matt P.

[BlueLava]

S60 2nd FP3

[timm-ah]

Hi - I don't have a clue where this example is (the source file you mention doesn't show up in my S60 2nd FP3 installation). However, I can compile that code file.

Does the project in question build from abld build or other IDE? Can you post a link to where to get this example?

Cheers,
Tim

[mpinsonneault]

Another obvious question -- are you able to build it from CodeWarrior, or from the command line? If it doesn't work from the command line it probably won't work inside any IDE either.

Matt P.

[BlueLava]

The example is here:

http://www.forum.nokia.com/info/sw.n..._v1_0.Zip.html

And yes, I can compile it in Visual Studio without any problems.

Emery

[madsum]

Hi BlueLava,

I was looking for that example project. I can visit the downloading page by your link. But I can't download it. It seems download link is broken. So will be kind enough to send me the project via email. My email addr is shumonmitu@hotmail.com. Thanking you in advance!

[BlueLava]

Hmm. The download seems to work for me, no problem. But ok. I'll send it.

[mitts]

Hi,

Basically Express only supports the target types listed in the Online Help/Release notes: APP, EXE; DLL and LIB, MDL is not on the supported list.

However, I was able to download the example, import it (Import ->Symbian MMP file) and build it succesfully with FP2 and FP3. I am not sure though that you would be able to use it from an other app, there might be issues related to the call interface (such as entry points), this is why it is not supported.

Is it possible that you are using a workspace with spaces or that you do not have yet perl installed or some other basic issue with your environment setup?

[BlueLava]

I am able to build other similarly small projects without problems. The path is without spaces, perl is installed or the other projects (and those in Visual Studio with carbide_vs) wouldn't compile.

The one thing I did differently is import the inf file and not the mmp file. I'll try that.

Thanks.

[BlueLava]

No, that still didn't do it. Here's the console:

'Building file: ../src/RecogEx.cpp'
'Invoking: GCC98 Complier'
gcc.exe -nostdinc -pipe -c -s -fomit-frame-pointer -O -march=armv4t -mthumb-interwork -DNDEBUG -D_UNICODE -D__SYMBIAN32__ -D__DLL__ -D__GCC32__ -D__EPOC32__ -D__MARM__ -D__MARM_ARMI__ -Wall -Wno-ctor-dtor-privacy -Wno-unknown-pragmas -I "D:\Projects_carb\RecogEx\inc" -I "D:\Symbian\8.1a\S60_2nd_FP3\epoc32\include" -o src/RecogEx.o ../src/RecogEx.cpp
'Finished building: ../src/RecogEx.cpp'
' '
make: *** No rule to make target `../RecogEx.cpp', needed by `RecogEx.o'.
'Building file: ../group/Bld.inf'
'Invoking: Def File Creator for GCC98'
perl.exe -S makedef.pl -Deffile ../group/Bld.inf "group/RecogEx.def"
../group/Bld.inf(1) : DEFFILE ERROR: Unrecognised Syntax "// BLD.INF"
make: *** [group/RecogEx.def] Error 255
make: Target `all' not remade because of errors.
Build complete for project RecogEx


Is something missing from the bld.inf file?

[mitts]

I think I might have solved your problem. Is it possible that you have brought the bld.inf file into the project - using something like Import -> File system - so that it is visible in the project explorer view? If yes, then you need to exclude it from the build, it seems that for some reason, the .inf ending matches some build rule that makes Carbide think that it needs to be built.

To exclude the file from builds, select the file and then right-click. From the menu choose Properties. Choose the "C/C++ Build" tab. Select "Exclude from build", click OK. Rebuild and hope for the best. If you have other files as well, these might need a similar treatment.

Even with this, there is still the risk that you cannot use the created file.

[BlueLava]

Now I got this error, but I haven't looked at it long yet.

'Building file: ../src/RecogEx.cpp'
'Invoking: GCC98 Complier'
gcc.exe -nostdinc -pipe -c -s -fomit-frame-pointer -O -march=armv4t -mthumb-interwork -DNDEBUG -D_UNICODE -D__SYMBIAN32__ -D__DLL__ -D__GCC32__ -D__EPOC32__ -D__MARM__ -D__MARM_ARMI__ -Wall -Wno-ctor-dtor-privacy -Wno-unknown-pragmas -I "D:\Projects_carb\RecogEx\inc" -I "D:\Symbian\8.1a\S60_2nd_FP3\epoc32\include" -o src/RecogEx.o ../src/RecogEx.cpp
'Finished building: ../src/RecogEx.cpp'
' '
make: *** No rule to make target `../RecogEx.cpp', needed by `RecogEx.o'.
make: Target `all' not remade because of errors.
Build complete for project RecogEx

[mitts]

Ok, so it seems that it tries to build the RecogEx.cpp twice, once out of /src once out of the project root?? Is it possible that you have 2 copies of the .cpp file in the project, one for some reason without a build step associated? Not that I could find any way to get a .cpp file into a project without assigning the correct build step.., unless you had tried to import it into vanilla Eclipse prior to installing Carbide?

Did you try to delete the full project selecting the "Also delete contents.. option? Note that if you do not do that, the next import will "adopt" the old project contents and you will propagate any problems that might have been there in the project setup? And then re-import it?

[BlueLava]

I only have one RecogEx.cpp. Yes I did delete the entire project and contents. I used a completely new project.

Here's something I just thought of and it resolves the issue. What I had been doing was copy the entire unzipped RecogEx folder from the sample into my workspace. When I imported either the .inf or .mmp file I did not check "Copy source files into workspace". I just used the existing folder.

I now import from another location and do select to copy the source files into the workspace. It compiles just fine.

I've used Eclipse for years for Java and J2ME, and never came across this behavior.

Thanks for sticking with me and helping resolve this problem.