Bug 188885

Summary:	missing AKONADI_PARAM_EXTERNALPAYLOAD to compile kdepimlibs
Product:	[Applications] kdepimlibs	Reporter:	Unknown <null>
Component:	syndication	Assignee:	kdepim bugs <kdepim-bugs>
Status:	RESOLVED FIXED
Severity:	normal	CC:	andresbajotierra, Frank-Roscher
Priority:	NOR
Version:	unspecified
Target Milestone:	---
Platform:	Compiled Sources
OS:	Other
Latest Commit:		Version Fixed In:
Sentry Crash Report:

Description Unknown 2009-04-05 15:34:53 UTC

Version:           akonadi-1.1.1-1 (using Devel)
Compiler:          g++ (GCC) 4.3.3 
OS:                Other
Installed from:    Compiled sources

trying to compile kdepimlibs (At revision 949543):
[ 18%] Building CXX object akonadi/CMakeFiles/akonadi-kde.dir/itemfetchjob.o
/home/gmarch/Software/kdepimlibs/src/akonadi/itemfetchjob.cpp: In member function 'void Akonadi::ItemFetchJobPrivate::startFetchJob()':
/home/gmarch/Software/kdepimlibs/src/akonadi/itemfetchjob.cpp:91: error: expected `;' before 'AKONADI_PARAM_EXTERNALPAYLOAD'

In the included file:
/usr/include/akonadi/private/protocol_p.h
the symbol is not defined

it might be a solution:
#define AKONADI_PARAM_EXTERNALPAYLOAD "AKONADI_PARAM_EXTERNALPAYLOAD"

such the three other one

Comment 1 Pino Toscano 2009-04-05 16:23:45 UTC

You need the trunk (aka development) version of Akonadi.
Any released version is not enough.

Comment 2 Frank Roscher 2009-04-06 14:17:35 UTC

I get the same here, using kdesvn-build.
Apparently the system's Akonadi in /usr is being used instead of the freshly-compiled trunk version in my home directory.

This is the only part of KDE where I encounter such a problem. This suggests to me that there is indeed a problem to be fixed, but I guess it could be kdesvn-build's fault, too.

Comment 3 Unknown 2009-04-06 18:19:13 UTC

I am very new here!
I got the trunk version of akonadi and the error is no more there. I use the cmakeke to do the job. I cannot confirm the comment #2 from Frank.

Comment 4 Dario Andres 2009-04-06 23:24:56 UTC

@Frank: probably the CMake (cached) scripts/files are still using the global (/usr) Akonadi version instead your local one. You may need to clean this cmake files and then try again to CMake to properly recognize and use the local one. Thanks

Comment 5 Frank Roscher 2009-04-07 13:16:11 UTC

(In reply to comment #4)
Dario: Thank you for your help, but in my case it was indeed kdesvn-build's fault :) I checked its changelog in trunk and found this:

Make kdesvn-build set the CMAKE_PREFIX_PATH environment variable, which allows builds to
complete successfully even when system packages are installed.

With this, it works. I guess it was just luck that no other part of KDE failed.
So, if somebody else complains to you about such a problem just tell him to use the trunk version of the script.

I think this bug can be closed now.

Comment 6 Allen Winter 2009-04-07 13:28:33 UTC

ok, closing