Re: Automoc4
On Tuesday 20 July 2010, Michael Jansen wrote: Hi I just noticed this line in automoc if(NOT _generated AND NOT _skip) Which means .h and .cpp files are ignored if they are generated and not automocced (?). Which i can't eyplain myself why and which bites me a bit. I try to automoc generated sources. If i give some files to automoc and don't explicitely tell it to skip them then why does it skip them? Anyone an idea why this is there? Have to check for the details again... If they are generated, is there a dependency which ensures that they already exist when automoc runs ? This maybe have been the reason IIRC. Just run moc directly on generated files, you probably already have a macro for generating them anyway, so calling qt4_wrap_cpp() directly for this file in that macro shouldn't be a problem. Alex ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Automoc4
Hi I just noticed this line in automoc if(NOT _generated AND NOT _skip) Which means .h and .cpp files are ignored if they are generated and not automocced (?). Which i can't eyplain myself why and which bites me a bit. I try to automoc generated sources. If i give some files to automoc and don't explicitely tell it to skip them then why does it skip them? Anyone an idea why this is there? Mike ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: Automoc4 problems on OSX
On 1 Mar 2010, at 22:03, Alexander Neundorf wrote: is -F included in INCLUDE_DIRECTORIES ? Nope but you can work it out from MOC_DIRECTORIES. If not, if on Mac, we need to check whether -F is in the link libraries. Hmm, but the target does not yet exist at this point. Hmm. Maybe automoc4 could check the location of the QtCore library and use this to determine whether and where Qt is installed as frameworks ? I've attached a patch for this. It should add all the needed frameworks. Seems to work for me. Can you review it and if it's OK I'll commit it. Where ? Do you mean in trunk or in a branch or in git ? Whereever you prefer :-) CMake just switched to git. Cool, I'll get started on this at some point. I'll probably start doing it in trunk, as long as I don't remove any functionality that should be fine, right? automoc4-frameworks.patch Description: Binary data -- Cheers, Mike Arthur http://mikearthur.co.uk ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: Automoc4 problems on OSX
On Monday 15 March 2010, Mike Arthur wrote: On 1 Mar 2010, at 22:03, Alexander Neundorf wrote: is -F included in INCLUDE_DIRECTORIES ? Nope but you can work it out from MOC_DIRECTORIES. If not, if on Mac, we need to check whether -F is in the link libraries. Hmm, but the target does not yet exist at this point. Hmm. Maybe automoc4 could check the location of the QtCore library and use this to determine whether and where Qt is installed as frameworks ? I've attached a patch for this. It should add all the needed frameworks. Seems to work for me. Can you review it and if it's OK I'll commit it. Hmm, I cannot really test it here, but it looks like it makes sense. So no objections from my side. Where ? Do you mean in trunk or in a branch or in git ? Whereever you prefer :-) CMake just switched to git. Cool, I'll get started on this at some point. I'll probably start doing it in trunk, as long as I don't remove any functionality that should be fine, right? Sure :-) If you do it in trunk, you can be sure people will scream as soon as you break something ;-) Alex ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: Automoc4 problems on OSX
On 15 Mar 2010, at 21:32, Alexander Neundorf wrote: Hmm, I cannot really test it here, but it looks like it makes sense. So no objections from my side. Great, I'll commit then. Where ? Do you mean in trunk or in a branch or in git ? Whereever you prefer :-) CMake just switched to git. Cool, I'll get started on this at some point. I'll probably start doing it in trunk, as long as I don't remove any functionality that should be fine, right? Sure :-) If you do it in trunk, you can be sure people will scream as soon as you break something ;-) The KDE developers can be my unit tests ;) Seriously though, I'll be careful. -- Cheers, Mike Arthur http://mikearthur.co.uk ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: Automoc4 problems on OSX
On Monday 15 March 2010, Mike Arthur wrote: On 15 Mar 2010, at 21:32, Alexander Neundorf wrote: ... If you do it in trunk, you can be sure people will scream as soon as you break something ;-) The KDE developers can be my unit tests ;) Well, actually, due to the big number of developers we have on Linux, we don't really need continuous builds for Linux... Just for all other platforms though. Alex ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: Automoc4 problems on OSX
On 26 Feb 2010, at 21:16, Alexander Neundorf wrote: Here I have include/QtGui/QGraphicsObject, so this looks correct. Where is this header on your system ? Is Qt installed as frameworks ? It's lib/QtGui.framework/Versions/4/Headers/QGraphicsObject for me. Yes I'm using frameworks on OSX 10.6 with Qt 4.6.2/Cocoa. -- Cheers, Mike Arthur http://mikearthur.co.uk ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: Automoc4 problems on OSX
On Mon, Mar 1, 2010 at 12:32 PM, Mike Arthur m...@mikearthur.co.uk wrote: On 26 Feb 2010, at 21:16, Alexander Neundorf wrote: Here I have include/QtGui/QGraphicsObject, so this looks correct. Where is this header on your system ? Is Qt installed as frameworks ? It's lib/QtGui.framework/Versions/4/Headers/QGraphicsObject for me. Yes I'm using frameworks on OSX 10.6 with Qt 4.6.2/Cocoa. As long as your -F's are right, then lib/QtGui.framework/Versions/4/Headers/QGraphicsObject should work with: #include QtGui/QGraphicsObject -- Benjamin Reed a.k.a. Ranger Rick Fink, KDE, and Mac OS X development Blog: http://www.raccoonfink.com/ Music: http://music.raccoonfink.com/ ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: Automoc4 problems on OSX
On 1 Mar 2010, at 17:34, Benjamin Reed wrote: As long as your -F's are right, then lib/QtGui.framework/Versions/4/Headers/QGraphicsObject should work with: #include QtGui/QGraphicsObject Yeh, it does work fine at compile time, it's automoc4 that's not finding it properly. -- Cheers, Mike Arthur http://mikearthur.co.uk ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: Automoc4 problems on OSX
On Monday 01 March 2010, Mike Arthur wrote: On 1 Mar 2010, at 17:34, Benjamin Reed wrote: As long as your -F's are right, then lib/QtGui.framework/Versions/4/Headers/QGraphicsObject should work with: #include QtGui/QGraphicsObject Yeh, it does work fine at compile time, it's automoc4 that's not finding it properly. Does automoc4 get the -F passed ? If so, then somebody needs to add support for -F to automoc... Alex ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: Automoc4 problems on OSX
On 1 Mar 2010, at 21:31, Alexander Neundorf wrote: Does automoc4 get the -F passed ? If so, then somebody needs to add support for -F to automoc... I would bet money that it doesn't get it passed. Also, re: automoc qt -stdc port, where should this be done? -- Cheers, Mike Arthur http://mikearthur.co.uk ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: Automoc4 problems on OSX
On Monday 01 March 2010, Mike Arthur wrote:
On 1 Mar 2010, at 21:31, Alexander Neundorf wrote:
Does automoc4 get the -F passed ?
If so, then somebody needs to add support for -F to automoc...
I would bet money that it doesn't get it passed.
From kdesupport/automoc/Automoc4Config.cmake:
if(_moc_files)
set(_automoc_source ${CMAKE_CURRENT_BINARY_DIR}/${_target_NAME}_automoc.cpp)
get_directory_property(_moc_incs INCLUDE_DIRECTORIES)
get_directory_property(_moc_defs DEFINITIONS)
get_directory_property(_moc_cdefs COMPILE_DEFINITIONS)
is -F included in INCLUDE_DIRECTORIES ?
If not, if on Mac, we need to check whether -F is in the link libraries. Hmm,
but the target does not yet exist at this point. Hmm. Maybe automoc4 could
check the location of the QtCore library and use this to determine whether
and where Qt is installed as frameworks ?
Also, re: automoc qt -stdc port, where should this be done?
Where ?
Do you mean in trunk or in a branch or in git ?
Whereever you prefer :-)
CMake just switched to git.
Alex
___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: Automoc4 problems on OSX
On Wednesday 24 February 2010, Mike Arthur wrote: Got more problems with Automoc4 on OSX unfortunately. I had to commit revision 1095725 to fix a bug. Without it I get this: [ 93%] Built target kcmremotewidgetshelper Generating applethandle_p.moc /Users/mike/Documents/KDE/KDELibs/plasma/private/applethandle_p.h:42: Error: Undefined interface automoc4: process for /Users/mike/Documents/KDE/KDELibs/b/plasma/applethandle_p.moc failed: Unknown error pid to wait for: 0 returning failed.. make[2]: *** [plasma/CMakeFiles/plasma_automoc] Error 1 make[1]: *** [plasma/CMakeFiles/plasma_automoc.dir/all] Error 2 make: *** [all] Error 2 To fix it I had to change: #include QtGui/QGraphicsObject to: ... #include QGraphicsObject This happens on automoc4 0.9.88 and the unreleased trunk (0.9.89). Here I have include/QtGui/QGraphicsObject, so this looks correct. Where is this header on your system ? Is Qt installed as frameworks ? Alex ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: Automoc4 problems on OSX
On 25 Feb 2010, at 02:46, Pavel Heimlich, a.k.a. hajma wrote: he meant to: #include QGraphicsObject http://websvn.kde.org/branches/KDE/4.4/kdelibs/plasma/private/applethandle_p.h?r1=1095725r2=1095724pathrev=1095725 Sorry, it was late and made a stupid typo. Pavel is correct, thanks! -- Cheers, Mike Arthur http://mikearthur.co.uk ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Automoc4 problems on OSX
Got more problems with Automoc4 on OSX unfortunately. I had to commit revision 1095725 to fix a bug. Without it I get this: [ 93%] Built target kcmremotewidgetshelper Generating applethandle_p.moc /Users/mike/Documents/KDE/KDELibs/plasma/private/applethandle_p.h:42: Error: Undefined interface automoc4: process for /Users/mike/Documents/KDE/KDELibs/b/plasma/applethandle_p.moc failed: Unknown error pid to wait for: 0 returning failed.. make[2]: *** [plasma/CMakeFiles/plasma_automoc] Error 1 make[1]: *** [plasma/CMakeFiles/plasma_automoc.dir/all] Error 2 make: *** [all] Error 2 To fix it I had to change: #include QtGui/QGraphicsObject to: #include QtGui/QGraphicsObject This happens on automoc4 0.9.88 and the unreleased trunk (0.9.89). -- Cheers, Mike Arthur http://mikearthur.co.uk ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: Automoc4 problems on OSX
On Wednesday 24 February 2010 19:56:01 Mike Arthur wrote: To fix it I had to change: #include QtGui/QGraphicsObject to: #include QtGui/QGraphicsObject Isn't that the same line? ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: Automoc4 problems on OSX
2010/2/25 Raphael Kubo da Costa kub...@gmail.com: On Wednesday 24 February 2010 19:56:01 Mike Arthur wrote: To fix it I had to change: #include QtGui/QGraphicsObject to: #include QtGui/QGraphicsObject Isn't that the same line? he meant to: #include QGraphicsObject http://websvn.kde.org/branches/KDE/4.4/kdelibs/plasma/private/applethandle_p.h?r1=1095725r2=1095724pathrev=1095725 ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: automoc4 corner issues - what lerned from qt-creator port
On Tuesday 24 March 2009 19:36:19 Helio Chissini de Castro wrote: 4 - w.cpp have an internal Q_OBJECT class and includes w.h with other class with Q_OBJECT but have no moc includes. Not sure I understand. If the class declaration is in w.cpp but no moc included how do you compile a moc file generated from that w.cpp file? Because in order to compile the generated moc file you need the class declaration, but that's only in w.cpp which you can't include from the moc... So what am I missing? -- Matthias Kretz (Germany) http://Vir.homelinux.org/ ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: automoc4 corner issues - what lerned from qt-creator port
On Wednesday 25 of March 2009 13:07:07 Matthias Kretz wrote:
On Tuesday 24 March 2009 19:36:19 Helio Chissini de Castro wrote:
4 - w.cpp have an internal Q_OBJECT class and includes w.h with other
class with Q_OBJECT but have no moc includes.
Not sure I understand. If the class declaration is in w.cpp but no moc
included how do you compile a moc file generated from that w.cpp file?
Because in order to compile the generated moc file you need the class
declaration, but that's only in w.cpp which you can't include from the
moc... So what am I missing?
Something like this:
w.cpp -
#include QObject
#include w.h
class Z : public QObject
{
Q_OBJECT
public:
Z() {};
};
W::W()
{
}
int main()
{
W w;
return 0;
}
---
w.h
#include QObject
class W : public QObject
{
Q_OBJECT;
public:
W();
};
-
So, as you see, both header and cpp have no moc includes
automoc4 test, see that aren't any includes, enter in the first situation
( matchOfset 0 ) and only test if there is Q_OBJECT on w.h or w_p.h,
suddenly generating a moc_w.cpp
But since we have a Z class in the cpp with a Q_OBJECT, they should be moc'd
as well, generating w.moc too. The revised last patch solve this case too
already.
--
Helio Chissini de Castro
KDE Developer
Brasil/South America Primary Contact
___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem
automoc4 corner issues - what lerned from qt-creator port
Hi
Since i finished the port of qt-creator build, i'm trying to identify why
automoc4 wasn't been able to build without patches adding moc_* in some codes
but qmake can.
DFaure helped a lot to identify the issue, and we have four corner cases to be
treated:
1 - w.cpp have an internal Q_OBJECT class and includes w.h with other class
with Q_OBJECT, and have on code #include moc_w.cpp and #include w.moc
2 - w.cpp have an internal Q_OBJECT class and includes w.h with other class
with Q_OBJECT, but have only w.moc
3 - w.cpp, independent of having internal Q_OBJECT class, includes a different
header, y.h with a Q_OBJECT class, but without correspondent y.cpp code
4 - w.cpp have an internal Q_OBJECT class and includes w.h with other class
with Q_OBJECT but have no moc includes.
qmake can handle all cases, based on addition of headers and sources on .pro,
so where and why automoc4 fails:
* On case 1: Autmoc4 works 100%
* On case 2: Automoc4 generates w.moc, but not generates moc_w.cpp. This
results in a linker error when using --no-undefined.
The case is that automoc4 detects the existency of a w.moc header and simply
discards the fact that exists an Q_OBJECT inside the cpp, so was a logic
question.
As automoc4 handles the case of having no moc includes, i did a patch that
test case 2 and solve case 2. Patch attached, don't know if is the best
approach
* On case 3: There's no way to do it automatically. Automoc4 can solve in
CMakeLists using AUTOMOC4_MOC_HEADERS( target y.h )
Is similar as qmake parsing headers, so in this case we still need add the
headers that not match for all the cases. A *perfect world* solution would be
automoc4 parse the local includes in source and verify if are standalone and
have Q_OBJECT, but is not a trivial change and should touch too much in the
current automoc4 structure. But is doable
* On case 4: The right behavior is add only w.moc, and of course not test the
.cpp, not generating moc_w.cpp falling in case 2. I'm expanding my patch to
cover this one.
For who want to help or test, i borrowed a dfaure's example an tweaked to be
Qt only and have w.cpp with all moc includes commented. Is located in
kdesvnserver/trunk/branches/work/~helio/
The default status is failing on case 3 and 4 leading to case 2.
[]'s
--
Helio Chissini de Castro
KDE Developer
Brasil/South America Primary Contact
--- kde4automoc.cpp 2009-01-22 16:50:09.0 -0200
+++ kde4automoc-new.cpp 2009-03-23 18:06:58.0 -0300
@@ -282,6 +282,7 @@
QHashQString, QString notIncludedMocs; // key = moc source filepath, value = moc output filename
QRegExp mocIncludeRegExp(QLatin1String([\n]\\s*#\\s*include\\s+[\]((?:[^ \]+/)?moc_[^ \/]+\\.cpp|[^ \]+\\.moc)[\]));
+QRegExp mocSourceIncludeRegExp(QLatin1String([\n]\\s*#\\s*include\\s+[\]((?:[^ \]+/)?moc_[^ \/]+\\.cpp)[\]));
QRegExp qObjectRegExp(QLatin1String([\n]\\s*Q_OBJECT\\b));
QStringList headerExtensions;
#if defined(Q_OS_WIN) || defined(Q_OS_MAC)
@@ -340,7 +341,10 @@
const QString absPath = sourceFileInfo.absolutePath() + '/';
Q_ASSERT(absPath.endsWith('/'));
int matchOffset = mocIncludeRegExp.indexIn(contentsString);
-if (matchOffset 0) {
+int matchSourceOffset = mocSourceIncludeRegExp.indexIn(contentsString);
+int matchQObject = qObjectRegExp.indexIn(QString::fromUtf8(contents));
+if ( ( matchSourceOffset 0 matchQObject = 0 ) || matchOffset 0 )
+{
// no moc #include, look whether we need to create a moc from the .h nevertheless
//qDebug() no moc #include in the .cpp file;
const QString basename = sourceFileInfo.completeBaseName();
@@ -374,7 +378,10 @@
break;
}
}
-} else {
+}
+
+if ( matchOffset = 0 )
+{
do { // call this for every moc include in the file
const QString currentMoc = mocIncludeRegExp.cap(1);
//qDebug() found moc include: currentMoc at offset matchOffset;
___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: automoc4 corner issues - what lerned from qt-creator port
missing patch
Attached is the new way better patch to handle cases 1, 2 and 4 correctly.
3 still have need use the automoc4_moc_headers
An interesting case for 3 is generated headers from .ui files,
[]'s
On Tuesday 24 of March 2009 15:36:19 Helio Chissini de Castro wrote:
Hi
Since i finished the port of qt-creator build, i'm trying to identify why
automoc4 wasn't been able to build without patches adding moc_* in some
codes but qmake can.
DFaure helped a lot to identify the issue, and we have four corner cases to
be treated:
1 - w.cpp have an internal Q_OBJECT class and includes w.h with other class
with Q_OBJECT, and have on code #include moc_w.cpp and #include w.moc
2 - w.cpp have an internal Q_OBJECT class and includes w.h with other class
with Q_OBJECT, but have only w.moc
3 - w.cpp, independent of having internal Q_OBJECT class, includes a
different header, y.h with a Q_OBJECT class, but without correspondent
y.cpp code
4 - w.cpp have an internal Q_OBJECT class and includes w.h with other class
with Q_OBJECT but have no moc includes.
qmake can handle all cases, based on addition of headers and sources on
.pro, so where and why automoc4 fails:
* On case 1: Autmoc4 works 100%
* On case 2: Automoc4 generates w.moc, but not generates moc_w.cpp. This
results in a linker error when using --no-undefined.
The case is that automoc4 detects the existency of a w.moc header and
simply discards the fact that exists an Q_OBJECT inside the cpp, so was a
logic question.
As automoc4 handles the case of having no moc includes, i did a patch that
test case 2 and solve case 2. Patch attached, don't know if is the best
approach
* On case 3: There's no way to do it automatically. Automoc4 can solve in
CMakeLists using AUTOMOC4_MOC_HEADERS( target y.h )
Is similar as qmake parsing headers, so in this case we still need add the
headers that not match for all the cases. A *perfect world* solution would
be automoc4 parse the local includes in source and verify if are standalone
and have Q_OBJECT, but is not a trivial change and should touch too much in
the current automoc4 structure. But is doable
* On case 4: The right behavior is add only w.moc, and of course not test
the .cpp, not generating moc_w.cpp falling in case 2. I'm expanding my
patch to cover this one.
For who want to help or test, i borrowed a dfaure's example an tweaked to
be Qt only and have w.cpp with all moc includes commented. Is located in
kdesvnserver/trunk/branches/work/~helio/
The default status is failing on case 3 and 4 leading to case 2.
[]'s
--
Helio Chissini de Castro
KDE Developer
Brasil/South America Primary Contact
--- kde4automoc.cpp 2009-01-22 16:50:09.0 -0200
+++ kde4automoc-new.cpp 2009-03-24 16:33:56.0 -0300
@@ -340,15 +340,27 @@
const QString absPath = sourceFileInfo.absolutePath() + '/';
Q_ASSERT(absPath.endsWith('/'));
int matchOffset = mocIncludeRegExp.indexIn(contentsString);
-if (matchOffset 0) {
+int matchQObject = qObjectRegExp.indexIn(QString::fromUtf8(contents));
+
+// Teste if .cpp file contains Q_OBJECT class and is not
+// already included
+const QString sourceName = sourceFileInfo.completeBaseName();
+
+
+qDebug() mocIncludeRegExp.capturedTexts();
+
+if (matchQObject ! mocIncludeRegExp.capturedTexts().contains(sourceName + .moc)) {
+notIncludedMocs.insert(absPath + sourceName + .cpp, sourceName + .moc );
+}
+
+if (matchOffset 0 || ! mocIncludeRegExp.capturedTexts().contains(moc_ + sourceName + .cpp)) {
// no moc #include, look whether we need to create a moc from the .h nevertheless
//qDebug() no moc #include in the .cpp file;
-const QString basename = sourceFileInfo.completeBaseName();
foreach (const QString ext, headerExtensions) {
-const QString headername = absPath + basename + ext;
+const QString headername = absPath + sourceName + ext;
if (QFile::exists(headername) !includedMocs.contains(headername)
!notIncludedMocs.contains(headername)) {
-const QString currentMoc = moc_ + basename + .cpp;
+const QString currentMoc = moc_ + sourceName + .cpp;
QFile header(headername);
header.open(QIODevice::ReadOnly);
const QByteArray contents = header.readAll();
@@ -360,10 +372,10 @@
}
}
foreach (const QString ext, headerExtensions) {
-const QString privateHeaderName = absPath + basename + _p + ext;
+const QString privateHeaderName = absPath + sourceName + _p + ext;
if (QFile::exists(privateHeaderName
Re: automoc4 issues ?
On Segunda-feira 09 Março 2009, David Faure wrote: On Monday 09 March 2009, Alexander Neundorf wrote: From your blog I assume you found the problem. What was wrong ? First, was the guy who are trying to compile the thing :-) But yes, thanks to DFaure explanations was all solved He had foo.h: Q_OBJECT and foo.cpp: Q_OBJECT and foo.cpp was including foo.moc, but not moc_foo.moc. So the moc file for the qobject in foo.cpp wasn't getting created. I used kdelibs/kdeui/fonts/kfontcombobox.cpp as example to find out he needed moc_foo.moc as well. Sounds like a bug in automoc, actually, if it's not handling this case... Would not be just a matter of process headers too ? Similar the way that qt4_wrap_cpp do, buy instead of explicitly put the headers on CMakeLists, just process the actual includes from cpp files. Just a guess -- Helio Chissini de Castro KDE Developer Brasil/South America Primary Contact ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
quanta compilation error; automoc4; bug/error report
Hello, When I tried to compile quanta from svn, I got error after executing cmake: CMake Error: File /automoc4.files.in does not exist CMake Error at /usr/lib/automoc4/Automoc4Config.cmake:243 (_add_automoc4_target) /usr/share/apps/cmake/modules/KDE4Macros.cmake:817 (_automoc4_kde4_pre_target_handling) src/CMakeLists.txt:20 (kde4_add_executable) On kde forum user bcooksley, told me to add -D_AUTOMOC4_CURRENT_DIR=/usr/lib/automoc4/ to cmake, and that fixed the problem. Regards Tomasz ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: automoc4 issues ?
On Thursday 05 March 2009, Helio Chissini de Castro wrote:
On Thursday 05 of March 2009 16:11:22 Helio Chissini de Castro wrote:
Hi
I'm trying to use automoc in a plugin system and got some issues.
I have:
set( Core_SRCS editormanager/openeditorsview.cpp )
set( Core_UI editormanager/openeditorsview.ui )
set( Core_MOC_HDRS editormanager/openeditorsview.h )
qt4_wrap_ui( Core_UI_SRCS ${Core_UI} )
qt4_wrap_cpp( Core_MOC_SRCS ${Core_MOC_HDRS}
*
If i use:
automoc4_add_library( Core SHARED ${Core_UI_SRCS} ${Core_SRCS} )
i got
[ 0%] Building CXX object
src/plugins/coreplugin/CMakeFiles/Core.dir/Core_automoc.cpp.o
In file included from
/home/lixo/packages/qt-creator/BUILD/qt-creator-1.0.0-
src/build/src/plugins/coreplugin/moc_openeditorsview.cpp:11,
from
/home/lixo/packages/qt-creator/BUILD/qt-creator-1.0.0-
src/build/src/plugins/coreplugin/Core_automoc.cpp:32:
/home/lixo/packages/qt-creator/BUILD/qt-creator-1.0.0-
src/build/src/plugins/coreplugin/../../../../src/plugins/coreplugin/edito
rm anager/openeditorsview.h:71: error: 'OpenEditorsView' in namespace
'Core::Internal::Ui' does not name a type
if i use:
add_library( Core SHARED ${Core_MOC_SRCS} ${Core_UI_SRCS} ${Core_SRCS} )
it works.
Is there something missing ?
Ok, David asked to to explain better the issue
I'm trying to make a cmake build for a Qt only application, in this case
qt- creator
One of the plugins, main one called coreplugin have some .ui forms too, and
i'm trying to use automoc4 to generate the plugin, but the above error
happens.
From your blog I assume you found the problem.
What was wrong ?
Alex
___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: automoc4 issues ?
On Monday 09 March 2009, Alexander Neundorf wrote:
On Thursday 05 March 2009, Helio Chissini de Castro wrote:
On Thursday 05 of March 2009 16:11:22 Helio Chissini de Castro wrote:
Hi
I'm trying to use automoc in a plugin system and got some issues.
I have:
set( Core_SRCS editormanager/openeditorsview.cpp )
set( Core_UI editormanager/openeditorsview.ui )
set( Core_MOC_HDRS editormanager/openeditorsview.h )
qt4_wrap_ui( Core_UI_SRCS ${Core_UI} )
qt4_wrap_cpp( Core_MOC_SRCS ${Core_MOC_HDRS}
*
If i use:
automoc4_add_library( Core SHARED ${Core_UI_SRCS} ${Core_SRCS} )
i got
[ 0%] Building CXX object
src/plugins/coreplugin/CMakeFiles/Core.dir/Core_automoc.cpp.o
In file included from
/home/lixo/packages/qt-creator/BUILD/qt-creator-1.0.0-
src/build/src/plugins/coreplugin/moc_openeditorsview.cpp:11,
from
/home/lixo/packages/qt-creator/BUILD/qt-creator-1.0.0-
src/build/src/plugins/coreplugin/Core_automoc.cpp:32:
/home/lixo/packages/qt-creator/BUILD/qt-creator-1.0.0-
src/build/src/plugins/coreplugin/../../../../src/plugins/coreplugin/edito
rm anager/openeditorsview.h:71: error: 'OpenEditorsView' in namespace
'Core::Internal::Ui' does not name a type
if i use:
add_library( Core SHARED ${Core_MOC_SRCS} ${Core_UI_SRCS} ${Core_SRCS} )
it works.
Is there something missing ?
Ok, David asked to to explain better the issue
I'm trying to make a cmake build for a Qt only application, in this case
qt- creator
One of the plugins, main one called coreplugin have some .ui forms too, and
i'm trying to use automoc4 to generate the plugin, but the above error
happens.
From your blog I assume you found the problem.
What was wrong ?
He had foo.h: Q_OBJECT
and foo.cpp: Q_OBJECT
and foo.cpp was including foo.moc, but not moc_foo.moc.
So the moc file for the qobject in foo.cpp wasn't getting created.
I used kdelibs/kdeui/fonts/kfontcombobox.cpp as example to find out
he needed moc_foo.moc as well.
Sounds like a bug in automoc, actually, if it's not handling this case...
--
David Faure, fa...@kde.org, sponsored by Qt Software @ Nokia to work on KDE,
Konqueror (http://www.konqueror.org), and KOffice (http://www.koffice.org).
___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: automoc4 issues ?
On Thursday 05 of March 2009 16:11:22 Helio Chissini de Castro wrote:
Hi
I'm trying to use automoc in a plugin system and got some issues.
I have:
set( Core_SRCS editormanager/openeditorsview.cpp )
set( Core_UI editormanager/openeditorsview.ui )
set( Core_MOC_HDRS editormanager/openeditorsview.h )
qt4_wrap_ui( Core_UI_SRCS ${Core_UI} )
qt4_wrap_cpp( Core_MOC_SRCS ${Core_MOC_HDRS}
*
If i use:
automoc4_add_library( Core SHARED ${Core_UI_SRCS} ${Core_SRCS} )
i got
[ 0%] Building CXX object
src/plugins/coreplugin/CMakeFiles/Core.dir/Core_automoc.cpp.o
In file included from
/home/lixo/packages/qt-creator/BUILD/qt-creator-1.0.0-
src/build/src/plugins/coreplugin/moc_openeditorsview.cpp:11,
from
/home/lixo/packages/qt-creator/BUILD/qt-creator-1.0.0-
src/build/src/plugins/coreplugin/Core_automoc.cpp:32:
/home/lixo/packages/qt-creator/BUILD/qt-creator-1.0.0-
src/build/src/plugins/coreplugin/../../../../src/plugins/coreplugin/editorm
anager/openeditorsview.h:71: error: 'OpenEditorsView' in namespace
'Core::Internal::Ui' does not name a type
if i use:
add_library( Core SHARED ${Core_MOC_SRCS} ${Core_UI_SRCS} ${Core_SRCS} )
it works.
Is there something missing ?
Ok, David asked to to explain better the issue
I'm trying to make a cmake build for a Qt only application, in this case qt-
creator
One of the plugins, main one called coreplugin have some .ui forms too, and
i'm trying to use automoc4 to generate the plugin, but the above error
happens.
Hope this helps to explain
--
Helio Chissini de Castro
Mandriva Research and Development
___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem
Automoc4 issue on x86_64
Hi, I have problem with the current svn and looks to be automoc4 related. This is a 64bit distro that uses /usr/lib64 for 64bit libs I have distro supplied automoc4 (0.9.84) in /usr/bin and the cmake modules for it in /usr/lib64/automoc4. cmake fails with: CMake Error at cmake/modules/FindPackageHandleStandardArgs.cmake:53 (MESSAGE): Did not find automoc4 (part of kdesupport). Call Stack (most recent call first): cmake/modules/FindAutomoc4.cmake:32 (find_package_handle_standard_args) cmake/modules/FindKDE4Internal.cmake:260 (find_package) CMakeLists.txt:33 (find_package) I tried to install the one from kdesupport to /opt/kde4, in that case the binary went to /opt/kde4/bin while the .cmake files to /opt/kde4/lib64/automoc4. Same error, even after passing - DCMAKE_PREFIX_PATH=/opt/kde4. The problem is that lib64, the cmake files are in lib64. If I move them to /opt/kde4/lib/automoc4, it works. Andras ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Patch to add two more automoc4 convenience macros
Hi,
for all the automoc4 users that cannot use KDE4Macros.cmake I'd like to add
the following two macros:
macro(ADD_AUTOMOC4_EXECUTABLE _target_NAME)
set(_SRCS ${ARGN})
set(_add_executable_param)
foreach(_argName WIN32 MACOSX_BUNDLE EXCLUDE_FROM_ALL)
list(GET _SRCS 0 _arg)
if(_arg STREQUAL _argName)
list(APPEND _add_executable_param ${_argName})
list(REMOVE_AT _SRCS 0)
endif(_arg STREQUAL _argName)
endforeach(_argName)
if(MSVC)
add_automoc4_target(${_target_NAME}_automoc _SRCS)
else(MSVC)
automoc4(${_target_NAME} _SRCS)
endif(MSVC)
add_executable(${_target_NAME} ${_add_executable_param} ${_SRCS})
if(MSVC)
add_dependencies(${_target_NAME} ${_target_NAME}_automoc)
endif(MSVC)
endmacro(ADD_AUTOMOC4_EXECUTABLE)
macro(ADD_AUTOMOC4_LIBRARY _target_NAME)
set(_SRCS ${ARGN})
set(_add_executable_param)
foreach(_argName STATIC SHARED MODULE EXCLUDE_FROM_ALL)
list(GET _SRCS 0 _arg)
if(_arg STREQUAL _argName)
list(APPEND _add_executable_param ${_argName})
list(REMOVE_AT _SRCS 0)
endif(_arg STREQUAL _argName)
endforeach(_argName)
if(MSVC)
add_automoc4_target(${_target_NAME}_automoc _SRCS)
else(MSVC)
automoc4(${_target_NAME} _SRCS)
endif(MSVC)
add_library(${_target_NAME} ${_add_executable_param} ${_SRCS})
if(MSVC)
add_dependencies(${_target_NAME} ${_target_NAME}_automoc)
endif(MSVC)
endmacro(ADD_AUTOMOC4_LIBRARY)
AFAICS we could then also switch the macros in KDE4Macros.cmake to use this.
--
Matthias Kretz (Germany)
http://Vir.homelinux.org/
[EMAIL PROTECTED], [EMAIL PROTECTED],
[EMAIL PROTECTED]
___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: Patch to add two more automoc4 convenience macros
On Tuesday 29 July 2008, Matthias Kretz wrote:
Hi,
for all the automoc4 users that cannot use KDE4Macros.cmake I'd like to add
the following two macros:
The names should be AUTOMOC4_ADD_EXECUTABLE() and AUTOMOC4_ADD_LIBRARY(), so
they conform to the cmake modules style guide.
macro(ADD_AUTOMOC4_EXECUTABLE _target_NAME)
set(_SRCS ${ARGN})
set(_add_executable_param)
foreach(_argName WIN32 MACOSX_BUNDLE EXCLUDE_FROM_ALL)
list(GET _SRCS 0 _arg)
if(_arg STREQUAL _argName)
list(APPEND _add_executable_param ${_argName})
list(REMOVE_AT _SRCS 0)
endif(_arg STREQUAL _argName)
endforeach(_argName)
I think that loop isn't perfect.
automoc4_add_executable(foo EXCLUDE_FROM_ALL WIN32 ${sources})
Here WIN32 will be ignored, right ?
It may make sense to add a special function for that to the cmake LIST()
command.
Alex
___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: [ANNOUNCE] automoc4 from kdesupport now supported for building KDE
On Friday 20 June 2008, Matthias Kretz wrote:
On Monday 16 June 2008 17:13:41 Matthias Kretz wrote:
Hmm, perhaps the target could be made explicit:
add_automoc4_target(phonon_automoc phonon_SRCS)
add_library(phonon ${phonon_SRCS})
add_dependencies(phonon phonon_automoc)
kde4_add_library/executable/plugin would hide all that.
Please test the attached patch (esp. on Windows) and let me know what you
think about this new automoc macro.
This patch adds the additional automoc target for every target.
KDE developers will complain that it got slower.
Can we have two versions of the macro, one with the extra target and one
without ?
The one with the extra target could be the one recommended for general use
outside of KDE. Inside KDE (i.e. KDE4Macros.cmake) the one without the extra
target could be used, except in the case where this doesn't work (nmake ?).
It should be possible to hide this in the KDE4_ADD_SOMETHING() macros.
What do you think ? Too much trouble for the speed gain ?
Another issue:
I think we should make kdesupport automoc mandatory ASAP. I won't be online a
lot next week. So if you feel like it is ready, can you please do that next
monday and remoev the old automoc from kdelibs at the same time ?
Alex
___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: [ANNOUNCE] automoc4 from kdesupport now supported for building KDE
On Thursday 05 June 2008, Alexander Neundorf wrote:
On Thursday 29 May 2008, Matthias Kretz wrote:
On Thursday 29 May 2008, Alexander Neundorf wrote:
On Wednesday 28 May 2008, Matthias Kretz wrote:
I tried add_custom_target and it won't work in the automoc macros
because there needs to be a dependency from the main target to the
automoc target. And that cannot be added from the automoc macro
because the main target is not defined at this point.
add_custom_command(TARGET has the same problem.
It would be possible to use add_custom_target and require the user to
add the dependency between the two targets himself. In the KDE4_
macros we could do that...
Yes, there it wouldn't be a problem.
Except that it is a bit slower, right ?
It's hard to profile. But it certainly has to read and write a lot more files
if you double the number of targets in a project. It should be noticable on
big modules like kdelibs and kdebase. Small modules won't notice it, I think.
Do you think this would be acceptable for other projects ?
It being slower or the need to add a dependency rule for a target that fell
from the sky?
Hmm, perhaps the target could be made explicit:
add_automoc4_target(phonon_automoc phonon_SRCS)
add_library(phonon ${phonon_SRCS})
add_dependencies(phonon phonon_automoc)
kde4_add_library/executable/plugin would hide all that.
--
Matthias Kretz (Germany)
http://Vir.homelinux.org/
[EMAIL PROTECTED], [EMAIL PROTECTED],
[EMAIL PROTECTED]
signature.asc
Description: This is a digitally signed message part.
___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: [ANNOUNCE] automoc4 from kdesupport now supported for building KDE
On Thursday 29 May 2008, Matthias Kretz wrote: On Thursday 29 May 2008, Alexander Neundorf wrote: On Wednesday 28 May 2008, Matthias Kretz wrote: On Tuesday 27 May 2008, Christian Ehrlicher wrote: Alexander Neundorf schrieb: On Saturday 10 May 2008, Alexander Neundorf wrote: Hi, we moved automoc (the tool which does the automoc'ing) to kdesupport, so it can be used also by non-KDE apps (and maybe be integrated into cmake). I think we can make automoc from kdesupport required next week, and delete the one from kdelibs. Or is there anything speaking against this ? Yes, my problem with nmake :) Any news on this? I tried add_custom_target and it won't work in the automoc macros because there needs to be a dependency from the main target to the automoc target. And that cannot be added from the automoc macro because the main target is not defined at this point. add_custom_command(TARGET has the same problem. It would be possible to use add_custom_target and require the user to add the dependency between the two targets himself. In the KDE4_ macros we could do that... Yes, there it wouldn't be a problem. Except that it is a bit slower, right ? Do you think this would be acceptable for other projects ? I mean it's a bit ugly, a target is created automatically without the developer knowing it, and then the developer has to do something with the target. (we have something similar for kdeinit, and this is already not nice). Alex ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: automoc4 from kdesupport now supported for building KDE
On 04.06.08 13:35:30, David Faure wrote:
On Tuesday 03 June 2008, Brad King wrote:
David Faure wrote:
Currently the
only way to override what the NO_DEFAULT_PATH stuff finds is to set the
result variable in the cache by hand for each and every library. If you
(as a project dev) want to look in a set of default locations on the
users' behalf, they should be added to the search path variables by the
project. Then none of the find_* commands needs special arguments, only
one call to each is needed, and users can override things easily.
But that means modifying global variables, i.e. affecting all other calls to
find_library?
This doesn't sound right. When looking for libbz2 we surely don't want to
look into
${KDE4_LIB_INSTALL_DIR} ${KDE4_LIB_DIR} ${QT_LIBRARY_DIR} ...
Well, you can first add them and then remove them again.
If you have variables like KDE4_LIB_INSTALL_DIR that are supposed to
tell you where to find the library, why do you need to search for it in
default paths at all?
Because those are just hints. Maybe phonon is in the kde install dir, but
maybe it has
been installed into its own prefix instead. In the first case it should
be autodetected,
while in the latter case it's normal that the user has to specify a
prefix -- but that doesn't
work because of NO_DEFAULT_PATH (which is only there so that the
autodetection
prefers KDE4_LIB_INSTALL_DIR over /usr/lib, not to prevent users from
setting the right
path manually!).
Okay, so follow the above advice:
find_package(FOO REQUIRED)
# Foo tells me where I might find other stuff.
list(APPEND CMAKE_PREFIX_PATH ${FOO_INSTALL_PREFIX})
find_library(BAR_LIBRARY NAMES bar)
# tada! BAR_LIBRARY is found under foo-prefix/lib
Yes. However this means not using NO_DEFAULT_PATH, so this brings up this
orthogonal issue:
Imagine I have a /usr/lib/libphonon.so from kubuntu (so it's old, and was
compiled in release mode),
and I compile my own libphonon.so into my own prefix (say
/opt/phonon/lib/libphonon.so or whatever).
IIRC a call to find_library() would prefer the one in /usr/lib/libphonon.so
even when doing
find_library(PHONON_LIBRARY NAMES phonon PATHS /opt/phonon/lib)
because the system paths are checked first (right? I hope I don't remember
wrongly).
Right, but with that call you could set CMAKE_PREFIX_PATH and have your
phonon in /opt found.
Right Alex? This is the reason for the NO_DEFAULT_PATH in FindPhonon? Or is
the reason
rather that you wanted CMAKE_SYSTEM_LIBRARY_PATH to have more priority than
qt's [old] phonon?
(but that's a tough choice, they could both be too old :)
Removing NO_DEFAULT_PATH fixes my problem (phonon is found when setting
CMAKE_PREFIX_PATH correctly)
OK about this patch, Alex?
No, thats wrong, it breaks when one has phonon in /usr/lib and also in
install dir, but the latter one should be used. You should add a second
call to find_library without NO_DEFAULT_PATH after the first one. That
uses phonon from KDE paths+CMAKE_SYSTEM_LIBRARY_PATH+install dir if
available and else uses the one that it finds in the default paths,
including CMAKE_PREFIX_PATH and CMAKE_LIBRARY_PATH variables.
Andreas
--
You're growing out of some of your problems, but there are others that
you're growing into.
___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: automoc4 from kdesupport now supported for building KDE
On Wednesday 04 June 2008, Andreas Pakulat wrote:
But that means modifying global variables, i.e. affecting all other calls
to find_library?
This doesn't sound right. When looking for libbz2 we surely don't want to
look into
${KDE4_LIB_INSTALL_DIR} ${KDE4_LIB_DIR} ${QT_LIBRARY_DIR} ...
Well, you can first add them and then remove them again.
Before and after *every* single call to find_library? Hello? This isn't
autoconf anymore, we are looking
for _convenient_ solutions here :)
Yes. However this means not using NO_DEFAULT_PATH, so this brings up this
orthogonal issue:
Imagine I have a /usr/lib/libphonon.so from kubuntu (so it's old, and was
compiled in release mode),
and I compile my own libphonon.so into my own prefix (say
/opt/phonon/lib/libphonon.so or whatever).
IIRC a call to find_library() would prefer the one in /usr/lib/libphonon.so
even when doing
find_library(PHONON_LIBRARY NAMES phonon PATHS /opt/phonon/lib)
because the system paths are checked first (right? I hope I don't remember
wrongly).
Right, but with that call you could set CMAKE_PREFIX_PATH and have your
phonon in /opt found.
But the code already mentions /opt/phonon/lib, so it should find it there
automatically.
For this we -do- want autoconf-like behavior: autodetection whenever possible,
otherwise
every user would have to set a huge number of variables when configuring any
kde module.
Personally I am testing things with everything in its own prefix, but most
people don't do that,
they use the same prefix for everything (say /usr/local, or some kde-related
prefix), and any
lib in that prefix should be found automatically, without even the need to set
CMAKE_PREFIX_PATH,
as long as we can, in the cmake modules code, figure out that likely default
path
(which we do. but it should have priority over /usr/lib!).
Right Alex? This is the reason for the NO_DEFAULT_PATH in FindPhonon? Or is
the reason
rather that you wanted CMAKE_SYSTEM_LIBRARY_PATH to have more priority than
qt's [old] phonon?
(but that's a tough choice, they could both be too old :)
Removing NO_DEFAULT_PATH fixes my problem (phonon is found when setting
CMAKE_PREFIX_PATH correctly)
OK about this patch, Alex?
No, thats wrong, it breaks when one has phonon in /usr/lib and also in
install dir, but the latter one should be used.
This is exactly what's wrong about find_library IMHO.
We need a way to get the following priority order:
* user-specified prefix (CMAKE_PREFIX_PATH)
* likely default locations (kde lib install dir etc.)
* system fallback defaults (/usr)
You should add a second
call to find_library without NO_DEFAULT_PATH after the first one.
That's ugly and we don't want to do that - as Brad said.
That
uses phonon from KDE paths+CMAKE_SYSTEM_LIBRARY_PATH+install dir if
available and else uses the one that it finds in the default paths,
including CMAKE_PREFIX_PATH and CMAKE_LIBRARY_PATH variables.
Those last two are user-specified, surely they should have priority?
Otherwise there's no way to override the builtin-default-locations like kde
install dir
or /usr/lib (that's what CMAKE_SYSTEM_LIBRARY_PATH is, isn't it?).
--
David Faure, [EMAIL PROTECTED], sponsored by Trolltech to work on KDE,
Konqueror (http://www.konqueror.org), and KOffice (http://www.koffice.org).
___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: automoc4 from kdesupport now supported for building KDE
On 04.06.08 14:25:09, David Faure wrote: On Wednesday 04 June 2008, Andreas Pakulat wrote: Right Alex? This is the reason for the NO_DEFAULT_PATH in FindPhonon? Or is the reason rather that you wanted CMAKE_SYSTEM_LIBRARY_PATH to have more priority than qt's [old] phonon? (but that's a tough choice, they could both be too old :) Removing NO_DEFAULT_PATH fixes my problem (phonon is found when setting CMAKE_PREFIX_PATH correctly) OK about this patch, Alex? No, thats wrong, it breaks when one has phonon in /usr/lib and also in install dir, but the latter one should be used. This is exactly what's wrong about find_library IMHO. We need a way to get the following priority order: * user-specified prefix (CMAKE_PREFIX_PATH) * likely default locations (kde lib install dir etc.) * system fallback defaults (/usr) You should add a second call to find_library without NO_DEFAULT_PATH after the first one. That's ugly and we don't want to do that - as Brad said. Then you need to file a bugreport for CMake and wait with the change until KDE can require the CMake version that implements it. Sometimes you'll have to either write your own or use a workaround for a limitation in a given system. That uses phonon from KDE paths+CMAKE_SYSTEM_LIBRARY_PATH+install dir if available and else uses the one that it finds in the default paths, including CMAKE_PREFIX_PATH and CMAKE_LIBRARY_PATH variables. Those last two are user-specified, surely they should have priority? You can read about the order of things in man cmake (under find_library section), but yes those have priority over everything else, i.e. they are found first. Andreas -- Tomorrow, you can be anywhere. ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: automoc4 from kdesupport now supported for building KDE
On Wednesday 04 June 2008, you wrote:
...
Imagine I have a /usr/lib/libphonon.so from kubuntu (so it's old, and was
compiled in release mode), and I compile my own libphonon.so into my own
prefix (say /opt/phonon/lib/libphonon.so or whatever). IIRC a call to
find_library() would prefer the one in /usr/lib/libphonon.so even when
doing find_library(PHONON_LIBRARY NAMES phonon PATHS /opt/phonon/lib)
because the system paths are checked first (right? I hope I don't remember
wrongly). This is the reason why we're using NO_DEFAULT_PATH everywhere --
but I agree, it's a workaround. Ideally we shouldn't have to use it. And
then setting CMAKE_PREFIX_PATH or cmake-2.4 similar vars would work.
Right Alex? This is the reason for the NO_DEFAULT_PATH in FindPhonon? Or is
the reason rather that you wanted CMAKE_SYSTEM_LIBRARY_PATH to have more
priority than qt's [old] phonon? (but that's a tough choice, they could
Hmm, today was the first time I had a look at that file.
Maybe Matthias copied this from FindAutomoc4.cmake, but there we have a very
special case (finding a non-library file in a library directory).
Usually I would do something like:
find_library(PHONON_LIBRARY NAMES phonon
PATHS ${KDE4_LIB_INSTALL_DIR}
NO_DEFAULT_PATH)
find_library(PHONON_LIBRARY NAMES phonon)
This would prefer libphonon.so in the kdelibs install dir. The next try would
be the location listed in CMAKE_PREFIX_PATH or CMAKE_LIBRARY_PATH, followed
by all the default dirs.
Would that work for you ?
Alex
___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: automoc4 from kdesupport now supported for building KDE
On Wednesday 04 June 2008, Brad King wrote: David Faure wrote: On Wednesday 04 June 2008, Brad King wrote: 1.) CMAKE_PREFIX_PATH from environment 2.) CMAKE_PREFIX_PATH from cmake variable Interesting; shouldn't the cmake variable (e.g. specified on the command line) be preferred over the environment variable (which could be set in .bashrc, i.e. it's less specific and less explicit than cmake -DCMAKE_PREFIX_PATH=?). It's a tough call. The user could also do CMAKE_PREFIX_PATH=... cmake ../src for a one-shot tweak, or the project author could write set(CMAKE_PREFIX_PATH ...) Hehe, indeed. But both are very uncommon (everyone uses -D syntax when calling cmake, and a project author wouldn't know what to set CMAKE_PREFIX_PATH to IMHO, or only as a result of a previous autodetection, which itself would have to follow the rules of reading the user's settings first :) ) which is even less specific. However, I think the common use cases would be the env var in a .bashrc and the cmake var in the cache or on the command line. Additionally, a build script could set the cache variable to make it work independently of the user's environment if it were preferred. This argues in favor of switching the order. So, the overall preferred order for specificity is 1.) current build tree (CMAKE_PREFIX_PATH var) 2.) user environment (CMAKE_PREFIX_PATH env) 3.) current project source (PATHS option) 4.) system environment (PATH env) 5.) platform conventions (CMAKE_SYSTEM_PREFIX_PATH) Does this make sense? Indeed it does. Making this order work would require projects to avoid setting the CMAKE_PREFIX_PATH variable and instead use the PATHS option. This seems to be what everyone expects anyway. Yes, it makes the syntax much nicer, compared to storing, setting, and restoring CMAKE_PREFIX_PATH. -- David Faure, [EMAIL PROTECTED], sponsored by Trolltech to work on KDE, Konqueror (http://www.konqueror.org), and KOffice (http://www.koffice.org). ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: automoc4 from kdesupport now supported for building KDE
On Wednesday 04 June 2008, David Faure wrote:
On Wednesday 04 June 2008, Andreas Pakulat wrote:
But that means modifying global variables, i.e. affecting all other
calls to find_library? This doesn't sound right. When looking for
libbz2 we surely don't want to look into ${KDE4_LIB_INSTALL_DIR}
${KDE4_LIB_DIR} ${QT_LIBRARY_DIR} ...
Well, you can first add them and then remove them again.
Before and after *every* single call to find_library? Hello? This isn't
autoconf anymore, we are looking for _convenient_ solutions here :)
Sadly that was the exact same thought I had.
Huh. I remember doing stupid shit like that for JuK's configure.in.in
Regards,
- Michael Pyne
signature.asc
Description: This is a digitally signed message part.
___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: automoc4 from kdesupport now supported for building KDE
On 04.06.08 18:06:00, Michael Pyne wrote:
On Wednesday 04 June 2008, David Faure wrote:
On Wednesday 04 June 2008, Andreas Pakulat wrote:
But that means modifying global variables, i.e. affecting all other
calls to find_library? This doesn't sound right. When looking for
libbz2 we surely don't want to look into ${KDE4_LIB_INSTALL_DIR}
${KDE4_LIB_DIR} ${QT_LIBRARY_DIR} ...
Well, you can first add them and then remove them again.
Before and after *every* single call to find_library? Hello? This isn't
autoconf anymore, we are looking for _convenient_ solutions here :)
Sadly that was the exact same thought I had.
I guess I just don't have suffered enough from automake (rarely got in
touch with it so far except for the usual make -f Makefile.cvs+configure) :)
Also I never said that its a good idea to do that, I just raised an
option.
Andreas
--
Keep emotionally active. Cater to your favorite neurosis.
___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: automoc4 from kdesupport now supported for building KDE
On Tuesday 03 June 2008, Alexander Neundorf wrote:
BTW, what are ${CMAKE_SYSTEM_PREFIX_PATH} and ${CMAKE_SYSTEM_LIBRARY_PATH}?
cmake --help-variable doesn't know them.
Hmm, maybe they are internal and intentionally undocumented.
Well, if you have to use them when you write a FindFoo.cmake module, then maybe
they should be documented :)
No, I just tried and it also doesn't say anything about CMAKE_PREFIX_PATH and
CMAKE_LIBRARY_PATH.
They are documented in the FIND_LIBRARY() documentation. To make sure this
won't be forgotten it would be nice if you could file a bug report in the
cmake bugtracker for that.
Hmm. My old login failed to work. Grmbl. OK new account created...
Ok, I added the missing paths (CMAKE_PREFIX_PATH, CMAKE_LIBRARY_PATH and
their
env. var equivalents) to the FIND_FILE() command in kdelibs/cmake/modules/.
If
that works fine we have to do the same in kdesupport/akonadi/ and phonon/.
Yes it works fine after copying FindAutomoc.cmake to phonon, please commit them
too.
So with cmake 2.4 you can now set the CMAKE_LIBRARY_PATH env. var to the lib
install dir of automoc.
Works.
With cmake 2.6 you can (and should) set the CMAKE_PREFIX_PATH env. var to all
your custom install prefixes.
Works too - nicer indeed.
Of course you can also manually set AUTOMOC4_CONFIG_FILE to the file, either
using -DAUTOMOC4_CONFIG_FILE or using cmake-gui.
Yeah, I could also run moc by hand :-P
P.S. the issue here is that I try to find a file which is not a library in a
subdir of the lib dirs, so FIND_LIBRARY() would be a good candidate, but
since it automatically adds prefixes and suffixes (lib and .so) that
doesn't work, so FIND_FILE() has to be used instead, and all paths where
FIND_LIBRARY() would search are added explicitely.
Maybe it would be easier to just use FIND_PROGRAM(automoc4) and then
check ../lib/automoc/ for the Automoc4Config.cmake file ?
Not really, since ../lib can be ../lib64 or ../lib32, and in theory one doesn't
have to
set things up that way at all...
A more standard solution (except on windows) would be a pkgconfig file I
guess...
But I'm fine with the way it is now, thanks for the fix.
--
David Faure, [EMAIL PROTECTED], sponsored by Trolltech to work on KDE,
Konqueror (http://www.konqueror.org), and KOffice (http://www.koffice.org).
___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: automoc4 from kdesupport now supported for building KDE
Alexander Neundorf wrote: On Tuesday 03 June 2008, Brad King wrote: Finding lib/automoc4/Automoc4Config.cmake is the exact purpose of find_package(). The CMake 2.6 version is *much* more powerful than 2.4 and completely solves the problem. Please make sure that Automoc4Config.cmake is installed in a way that will work with find_package so that when CMake 2.6 is required it doesn't have to move. Yes, that works. But it also has to work with cmake 2.4, that's why I'm using that FIND_FILE() call. What I'm saying is that you should write it and get it working with find_package first and then go back and produce an approximation of it with find_file that is used for 2.4. That way the final design in a year when we require 2.6 is the right one and not a compatibility hack like the current foo_LIB_DEPENDS stuff. -Brad ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: automoc4 from kdesupport now supported for building KDE
On Tuesday 03 June 2008, Alexander Neundorf wrote: Hmm. My old login failed to work. Grmbl. OK new account created... Done, http://public.kitware.com/Bug/view.php?id=7146 I guess blogging about this once wasn't enough... ...how could anybody not remember all details from the blog of some KDE developer... Blogging? What's that? I don't have time to read blogs -and- mailinglists and fix kde bugs, sorry :) Hmm, techbase... Yes -- and of course the cmake documentation itself (added CMAKE_PREFIX_PATH to report 7146...) A more standard solution (except on windows) would be a pkgconfig file I guess... If you install automoc to a custom location, you would also have to adjust the PKGCONFIG_PATH (or what the name is) env. var, so it doesn't help for the basic issue. Sure it would need to be set, but it would help because it's more standard, so more commonly known ;) I already do this to PKG_CONFIG_PATH: headCat PKG_CONFIG_PATH $DBUSDIR/lib/pkgconfig headCat PKG_CONFIG_PATH $QTDIR/lib/pkgconfig headCat PKG_CONFIG_PATH /d/other/inst/icecream/lib/pkgconfig headCat PKG_CONFIG_PATH /d/other/inst/lib/pkgconfig # for qca headCat PKG_CONFIG_PATH /d/kde/inst/kdesupport_trunk/lib/pkgconfig :) -- David Faure, [EMAIL PROTECTED], sponsored by Trolltech to work on KDE, Konqueror (http://www.konqueror.org), and KOffice (http://www.koffice.org). ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: automoc4 from kdesupport now supported for building KDE
On Tuesday 03 June 2008, David Faure wrote:
On Tuesday 03 June 2008, Alexander Neundorf wrote:
BTW, what are ${CMAKE_SYSTEM_PREFIX_PATH} and
${CMAKE_SYSTEM_LIBRARY_PATH}? cmake --help-variable doesn't know them.
Hmm, maybe they are internal and intentionally undocumented.
Well, if you have to use them when you write a FindFoo.cmake module, then
maybe they should be documented :)
No, I just tried and it also doesn't say anything about CMAKE_PREFIX_PATH
and CMAKE_LIBRARY_PATH.
They are documented in the FIND_LIBRARY() documentation. To make sure
this won't be forgotten it would be nice if you could file a bug report
in the cmake bugtracker for that.
Hmm. My old login failed to work. Grmbl. OK new account created...
Ok, I added the missing paths (CMAKE_PREFIX_PATH, CMAKE_LIBRARY_PATH and
their env. var equivalents) to the FIND_FILE() command in
kdelibs/cmake/modules/. If that works fine we have to do the same in
kdesupport/akonadi/ and phonon/.
Yes it works fine after copying FindAutomoc.cmake to phonon, please commit
them too.
Will do.
So with cmake 2.4 you can now set the CMAKE_LIBRARY_PATH env. var to the
lib install dir of automoc.
Works.
With cmake 2.6 you can (and should) set the CMAKE_PREFIX_PATH env. var to
all your custom install prefixes.
Works too - nicer indeed.
I guess blogging about this once wasn't enough...
...how could anybody not remember all details from the blog of some KDE
developer...
Hmm, techbase...
Of course you can also manually set AUTOMOC4_CONFIG_FILE to the file,
either using -DAUTOMOC4_CONFIG_FILE or using cmake-gui.
Yeah, I could also run moc by hand :-P
P.S. the issue here is that I try to find a file which is not a library
in a subdir of the lib dirs, so FIND_LIBRARY() would be a good candidate,
but since it automatically adds prefixes and suffixes (lib and .so)
that doesn't work, so FIND_FILE() has to be used instead, and all paths
where FIND_LIBRARY() would search are added explicitely.
Maybe it would be easier to just use FIND_PROGRAM(automoc4) and then
check ../lib/automoc/ for the Automoc4Config.cmake file ?
Not really, since ../lib can be ../lib64 or ../lib32, and in theory one
doesn't have to set things up that way at all...
A more standard solution (except on windows) would be a pkgconfig file I
guess...
If you install automoc to a custom location, you would also have to adjust the
PKGCONFIG_PATH (or what the name is) env. var, so it doesn't help for the
basic issue.
Alex
___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: automoc4 from kdesupport now supported for building KDE
On Tuesday 03 June 2008, Brad King wrote: David Faure wrote: On Tuesday 03 June 2008, Alexander Neundorf wrote: Hmm. My old login failed to work. Grmbl. OK new account created... Done, http://public.kitware.com/Bug/view.php?id=7146 I guess blogging about this once wasn't enough... ...how could anybody not remember all details from the blog of some KDE developer... Blogging? What's that? I don't have time to read blogs -and- mailinglists and fix kde bugs, sorry :) Hmm, techbase... Yes -- and of course the cmake documentation itself (added CMAKE_PREFIX_PATH to report 7146...) From cmake --help-command find_library: 1. Search cmake specific environment variables. ... prefix/lib for each prefix in CMAKE_PREFIX_PATH ... 2. Search cmake variables with the same names as the cmake specific environment variables. ... prefix/lib for each prefix in CMAKE_PREFIX_PATH ... ...and similarly for the other find_* commands. Yes. This is nice for the cmake-code-writer, but not for the cmake user, who doesn't know find_library is involved in the first place. If someone tells that user just set CMAKE_PREFIX_PATH, he's going to do cmake --help-variable CMAKE_PREFIX_PATH, like I did :) What's cmake --help-variable good for, if it doesn't have all useful variables? Well, == http://public.kitware.com/Bug/view.php?id=7146 :) KDE developers, always complaining, I know :) But at least phonon compiles now so I'm happy :) -- David Faure, [EMAIL PROTECTED], sponsored by Trolltech to work on KDE, Konqueror (http://www.konqueror.org), and KOffice (http://www.koffice.org). ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: automoc4 from kdesupport now supported for building KDE
From cmake --help-command find_library:
If NO_DEFAULT_PATH is specified, then no additional paths are added to the
search.
This is in fact the reason why now kdelibs can't find phonon.
find_library(PHONON_LIBRARY NAMES phonon PATHS ${KDE4_LIB_INSTALL_DIR}
${KDE4_LIB_DIR} ${CMAKE_SYSTEM_LIBRARY_PATH} ${QT_LIBRARY_DIR}
${LIB_INSTALL_DIR} NO_DEFAULT_PATH)
So -DCMAKE_PREFIX_PATH:PATH=/d/kde/inst/kdesupport_trunk;/d/kde/inst/phonon
(correct syntax, right?)
doesn't work, because of the NO_DEFAULT_PATH. The reason why use
NO_DEFAULT_PATH almost everywhere
is simple: without it, libs in /usr/lib are preferred over those in the PATHS
specified to find_library.
Is there a way to get check those paths first, then fallback to the default
paths behavior, without duplicating
all the default paths in the find_library call?
--
David Faure, [EMAIL PROTECTED], sponsored by Trolltech to work on KDE,
Konqueror (http://www.konqueror.org), and KOffice (http://www.koffice.org).
___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: automoc4 from kdesupport now supported for building KDE
David Faure wrote:
From cmake --help-command find_library:
If NO_DEFAULT_PATH is specified, then no additional paths are added to the
search.
This is in fact the reason why now kdelibs can't find phonon.
find_library(PHONON_LIBRARY NAMES phonon PATHS ${KDE4_LIB_INSTALL_DIR}
${KDE4_LIB_DIR} ${CMAKE_SYSTEM_LIBRARY_PATH} ${QT_LIBRARY_DIR}
${LIB_INSTALL_DIR} NO_DEFAULT_PATH)
So -DCMAKE_PREFIX_PATH:PATH=/d/kde/inst/kdesupport_trunk;/d/kde/inst/phonon
(correct syntax, right?)
doesn't work, because of the NO_DEFAULT_PATH. The reason why use
NO_DEFAULT_PATH almost everywhere
is simple: without it, libs in /usr/lib are preferred over those in the PATHS
specified to find_library.
The issue here is that we (cmake devs) view the PATHS argument as a list
of last resort paths (e.g. hard-coding c:/Python25), not preferred
paths. There are a whole bunch of user-controlled places that are
searched before /usr/lib.
If you have variables like KDE4_LIB_INSTALL_DIR that are supposed to
tell you where to find the library, why do you need to search for it in
default paths at all?
When CMake 2.6 is required everything should switch to using the
export/import feature:
http://www.cmake.org/Wiki/CMake_2.6_Notes#Exporting_and_Importing_Targets
along with the full power of find_package and this issue should go away
completely. CMake will then just load a file that tells it exactly
where libraries are located (i.e. full paths to the library files).
Is there a way to get check those paths first, then fallback to the default
paths behavior, without duplicating
all the default paths in the find_library call?
Yes, and it's mentioned in the find_library documentation:
find_library(FOO_LIBRARY NAMES foo
PATHS ${PATH1} ${PATH2} ... NO_DEFAULT_PATH)
find_library(FOO_LIBRARY NAMES foo)
-Brad
___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: automoc4 from kdesupport now supported for building KDE
On 03.06.08 21:02:50, David Faure wrote:
From cmake --help-command find_library:
If NO_DEFAULT_PATH is specified, then no additional paths are added to the
search.
This is in fact the reason why now kdelibs can't find phonon.
find_library(PHONON_LIBRARY NAMES phonon PATHS ${KDE4_LIB_INSTALL_DIR}
${KDE4_LIB_DIR} ${CMAKE_SYSTEM_LIBRARY_PATH} ${QT_LIBRARY_DIR}
${LIB_INSTALL_DIR} NO_DEFAULT_PATH)
So -DCMAKE_PREFIX_PATH:PATH=/d/kde/inst/kdesupport_trunk;/d/kde/inst/phonon
(correct syntax, right?)
doesn't work, because of the NO_DEFAULT_PATH. The reason why use
NO_DEFAULT_PATH almost everywhere
is simple: without it, libs in /usr/lib are preferred over those in the PATHS
specified to find_library.
Is there a way to get check those paths first, then fallback to the default
paths behavior, without duplicating
all the default paths in the find_library call?
Yes there is, run find_library twice, first with NO_DEFAULT_PATH, then
without it. That way the directories that you list are preferred and you
can still easily search the standard system dirs if nothing is found in
the preferred dirs. Works because find_library doesn't search if the
variable it is supposed to fill is already filled with something that
doesn't end in -NOTFOUND.
Andreas
--
You will have a long and boring life.
___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: automoc4 from kdesupport now supported for building KDE
On Tuesday 03 June 2008, Brad King wrote:
David Faure wrote:
From cmake --help-command find_library:
If NO_DEFAULT_PATH is specified, then no additional paths are added to the
search.
This is in fact the reason why now kdelibs can't find phonon.
find_library(PHONON_LIBRARY NAMES phonon PATHS ${KDE4_LIB_INSTALL_DIR}
${KDE4_LIB_DIR} ${CMAKE_SYSTEM_LIBRARY_PATH} ${QT_LIBRARY_DIR}
${LIB_INSTALL_DIR} NO_DEFAULT_PATH)
So -DCMAKE_PREFIX_PATH:PATH=/d/kde/inst/kdesupport_trunk;/d/kde/inst/phonon
(correct syntax, right?)
doesn't work, because of the NO_DEFAULT_PATH. The reason why use
NO_DEFAULT_PATH almost everywhere
is simple: without it, libs in /usr/lib are preferred over those in the
PATHS specified to find_library.
The issue here is that we (cmake devs) view the PATHS argument as a list
of last resort paths (e.g. hard-coding c:/Python25), not preferred
paths. There are a whole bunch of user-controlled places that are
searched before /usr/lib.
This assumes that users specify all their lib locations as arguments. It's nice
to be able
to do that, but ideally things should just work out of the box, that's the
whole point
of that list of paths -- to try and autodetect where the stuff is installed, to
save the
user some work.
If you have variables like KDE4_LIB_INSTALL_DIR that are supposed to
tell you where to find the library, why do you need to search for it in
default paths at all?
Because those are just hints. Maybe phonon is in the kde install dir, but maybe
it has
been installed into its own prefix instead. In the first case it should be
autodetected,
while in the latter case it's normal that the user has to specify a prefix --
but that doesn't
work because of NO_DEFAULT_PATH (which is only there so that the autodetection
prefers KDE4_LIB_INSTALL_DIR over /usr/lib, not to prevent users from setting
the right
path manually!).
When CMake 2.6 is required everything should switch to using the
export/import feature:
http://www.cmake.org/Wiki/CMake_2.6_Notes#Exporting_and_Importing_Targets
along with the full power of find_package and this issue should go away
completely. CMake will then just load a file that tells it exactly
where libraries are located (i.e. full paths to the library files).
... as long as it finds that file in the first place, so I'm not sure this
changes anything, in fact.
Autodetection wanted when possible, manual setting of own prefix otherwise...
Is there a way to get check those paths first, then fallback to the
default paths behavior, without duplicating
all the default paths in the find_library call?
Yes, and it's mentioned in the find_library documentation:
find_library(FOO_LIBRARY NAMES foo
PATHS ${PATH1} ${PATH2} ... NO_DEFAULT_PATH)
find_library(FOO_LIBRARY NAMES foo)
Ah, right, I remember seeing this. It looks ugly and redundant, but ok :-)
--
David Faure, [EMAIL PROTECTED], sponsored by Trolltech to work on KDE,
Konqueror (http://www.konqueror.org), and KOffice (http://www.koffice.org).
___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: automoc4 from kdesupport now supported for building KDE
On Tuesday 03 June 2008, you wrote: Alexander Neundorf wrote: On Tuesday 03 June 2008, Brad King wrote: Finding lib/automoc4/Automoc4Config.cmake is the exact purpose of find_package(). The CMake 2.6 version is *much* more powerful than 2.4 and completely solves the problem. Please make sure that Automoc4Config.cmake is installed in a way that will work with find_package so that when CMake 2.6 is required it doesn't have to move. Yes, that works. But it also has to work with cmake 2.4, that's why I'm using that FIND_FILE() call. What I'm saying is that you should write it and get it working with find_package first Using just plain FIND_PACKAGE(Automoc4) (i.e. without extra FindAutomoc4.cmake) works, I checked that before. Do you mean that or something different ? Alex ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: automoc4 from kdesupport now supported for building KDE
Alexander Neundorf wrote: On Tuesday 03 June 2008, you wrote: Alexander Neundorf wrote: On Tuesday 03 June 2008, Brad King wrote: Finding lib/automoc4/Automoc4Config.cmake is the exact purpose of find_package(). The CMake 2.6 version is *much* more powerful than 2.4 and completely solves the problem. Please make sure that Automoc4Config.cmake is installed in a way that will work with find_package so that when CMake 2.6 is required it doesn't have to move. Yes, that works. But it also has to work with cmake 2.4, that's why I'm using that FIND_FILE() call. What I'm saying is that you should write it and get it working with find_package first Using just plain FIND_PACKAGE(Automoc4) (i.e. without extra FindAutomoc4.cmake) works, I checked that before. Do you mean that or something different ? That's all I meant. I just wanted to make sure. Thanks, -Brad ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: automoc4 from kdesupport now supported for building KDE
David Faure wrote:
On Tuesday 03 June 2008, Brad King wrote:
The issue here is that we (cmake devs) view the PATHS argument as a list
of last resort paths (e.g. hard-coding c:/Python25), not preferred
paths. There are a whole bunch of user-controlled places that are
searched before /usr/lib.
This assumes that users specify all their lib locations as arguments. It's
nice to be able
to do that, but ideally things should just work out of the box, that's the
whole point
of that list of paths -- to try and autodetect where the stuff is installed,
to save the
user some work.
The motivation behind our view is that users should be able to set
CMAKE_PREFIX_PATH and have CMake find things there first. Currently the
only way to override what the NO_DEFAULT_PATH stuff finds is to set the
result variable in the cache by hand for each and every library. If you
(as a project dev) want to look in a set of default locations on the
users' behalf, they should be added to the search path variables by the
project. Then none of the find_* commands needs special arguments, only
one call to each is needed, and users can override things easily.
If you have variables like KDE4_LIB_INSTALL_DIR that are supposed to
tell you where to find the library, why do you need to search for it in
default paths at all?
Because those are just hints. Maybe phonon is in the kde install dir, but
maybe it has
been installed into its own prefix instead. In the first case it should be
autodetected,
while in the latter case it's normal that the user has to specify a prefix --
but that doesn't
work because of NO_DEFAULT_PATH (which is only there so that the autodetection
prefers KDE4_LIB_INSTALL_DIR over /usr/lib, not to prevent users from setting
the right
path manually!).
Okay, so follow the above advice:
find_package(FOO REQUIRED)
# Foo tells me where I might find other stuff.
list(APPEND CMAKE_PREFIX_PATH ${FOO_INSTALL_PREFIX})
find_library(BAR_LIBRARY NAMES bar)
# tada! BAR_LIBRARY is found under foo-prefix/lib
If the user specifies a custom CMAKE_PREFIX_PATH it will override what
FOO says. In practice the find_library will be in a find script or
something.
When CMake 2.6 is required everything should switch to using the
export/import feature:
http://www.cmake.org/Wiki/CMake_2.6_Notes#Exporting_and_Importing_Targets
along with the full power of find_package and this issue should go away
completely. CMake will then just load a file that tells it exactly
where libraries are located (i.e. full paths to the library files).
... as long as it finds that file in the first place, so I'm not sure this
changes anything, in fact.
Autodetection wanted when possible, manual setting of own prefix otherwise...
The idea is that that one file is found by find_package, which is
extremely powerful (more powerful than pkgconfig, in fact). It also
works well on Windows and OS X (with frameworks too).
Is there a way to get check those paths first, then fallback to the
default paths behavior, without duplicating
all the default paths in the find_library call?
Yes, and it's mentioned in the find_library documentation:
find_library(FOO_LIBRARY NAMES foo
PATHS ${PATH1} ${PATH2} ... NO_DEFAULT_PATH)
find_library(FOO_LIBRARY NAMES foo)
Ah, right, I remember seeing this. It looks ugly and redundant, but ok :-)
We don't really want this done so it's okay if it's ugly. See above.
-Brad
___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: automoc4 from kdesupport now supported for building KDE
Brad King wrote: David Faure wrote: On Tuesday 03 June 2008, Brad King wrote: CMake will then just load a file that tells it exactly where libraries are located (i.e. full paths to the library files). ... as long as it finds that file in the first place, so I'm not sure this changes anything, in fact. Autodetection wanted when possible, manual setting of own prefix otherwise... The idea is that that one file is found by find_package, which is extremely powerful (more powerful than pkgconfig, in fact). It also works well on Windows and OS X (with frameworks too). Furthermore, the one file can tell CMake where to find all the libraries, headers, resources, etc. that come with the package. This avoids accidental mismatches of header files and libraries. Switching from one installation of the package to another requires only one cache variable to be changed. Unlike pkgconfig the one file can just be placed inside the package install tree instead of in a special location in the prefix. It can also do versioning (i.e. find version 4.1 of the package). -Brad ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: [ANNOUNCE] automoc4 from kdesupport now supported for building KDE
Hi David,
/me is still catching up with emails after LinuxTag...
On Thursday 29 May 2008, you wrote:
On Saturday 10 May 2008, Alexander Neundorf wrote:
Hi,
we moved automoc (the tool which does the automoc'ing) to kdesupport, so
it can be used also by non-KDE apps (and maybe be integrated into cmake).
When kdesupport is installed into its own prefix, how should automoc4 be
found? There's no pkgconfig file,
-DCMAKE_LIBRARY_PATH=/d/kde/inst/kdesupport_trunk/lib doesn't seem to
help
You are right, there was something missing.
FindAutomoc4.cmake says
find_file(AUTOMOC4_CONFIG_FILE NAMES Automoc4Config.cmake
PATH_SUFFIXES automoc4 lib/automoc4 lib64/automoc4
PATHS ${CMAKE_SYSTEM_PREFIX_PATH} ${CMAKE_SYSTEM_LIBRARY_PATH}
${CMAKE_INSTALL_PREFIX}/lib NO_DEFAULT_PATH )
-- how do I specify a path that isn't installprefix/lib for looking up
automoc4?
BTW, what are ${CMAKE_SYSTEM_PREFIX_PATH} and ${CMAKE_SYSTEM_LIBRARY_PATH}?
cmake --help-variable doesn't know them.
Hmm, maybe they are internal and intentionally undocumented.
No, I just tried and it also doesn't say anything about CMAKE_PREFIX_PATH and
CMAKE_LIBRARY_PATH.
They are documented in the FIND_LIBRARY() documentation. To make sure this
won't be forgotten it would be nice if you could file a bug report in the
cmake bugtracker for that.
Ok, I added the missing paths (CMAKE_PREFIX_PATH, CMAKE_LIBRARY_PATH and their
env. var equivalents) to the FIND_FILE() command in kdelibs/cmake/modules/. If
that works fine we have to do the same in kdesupport/akonadi/ and phonon/.
So with cmake 2.4 you can now set the CMAKE_LIBRARY_PATH env. var to the lib
install dir of automoc.
With cmake 2.6 you can (and should) set the CMAKE_PREFIX_PATH env. var to all
your custom install prefixes.
Of course you can also manually set AUTOMOC4_CONFIG_FILE to the file, either
using -DAUTOMOC4_CONFIG_FILE or using cmake-gui.
Alex
P.S. the issue here is that I try to find a file which is not a library in a
subdir of the lib dirs, so FIND_LIBRARY() would be a good candidate, but
since it automatically adds prefixes and suffixes (lib and .so) that
doesn't work, so FIND_FILE() has to be used instead, and all paths where
FIND_LIBRARY() would search are added explicitely.
Maybe it would be easier to just use FIND_PROGRAM(automoc4) and then
check ../lib/automoc/ for the Automoc4Config.cmake file ?
___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: [ANNOUNCE] automoc4 from kdesupport now supported for building KDE
On Saturday 10 May 2008, Alexander Neundorf wrote:
Hi,
we moved automoc (the tool which does the automoc'ing) to kdesupport, so it
can be used also by non-KDE apps (and maybe be integrated into cmake).
When kdesupport is installed into its own prefix, how should automoc4 be found?
There's no pkgconfig file,
-DCMAKE_LIBRARY_PATH=/d/kde/inst/kdesupport_trunk/lib doesn't seem to help
FindAutomoc4.cmake says
find_file(AUTOMOC4_CONFIG_FILE NAMES Automoc4Config.cmake
PATH_SUFFIXES automoc4 lib/automoc4 lib64/automoc4
PATHS ${CMAKE_SYSTEM_PREFIX_PATH} ${CMAKE_SYSTEM_LIBRARY_PATH}
${CMAKE_INSTALL_PREFIX}/lib
NO_DEFAULT_PATH )
-- how do I specify a path that isn't installprefix/lib for looking up
automoc4?
BTW, what are ${CMAKE_SYSTEM_PREFIX_PATH} and ${CMAKE_SYSTEM_LIBRARY_PATH}?
cmake --help-variable doesn't know them.
--
David Faure, [EMAIL PROTECTED], sponsored by Trolltech to work on KDE,
Konqueror (http://www.konqueror.org), and KOffice (http://www.koffice.org).
___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: [ANNOUNCE] automoc4 from kdesupport now supported for building KDE
On Wednesday 28 May 2008, Matthias Kretz wrote:
On Tuesday 27 May 2008, Christian Ehrlicher wrote:
Alexander Neundorf schrieb:
On Saturday 10 May 2008, Alexander Neundorf wrote:
Hi,
we moved automoc (the tool which does the automoc'ing) to kdesupport,
so it can be used also by non-KDE apps (and maybe be integrated into
cmake).
I think we can make automoc from kdesupport required next week, and
delete the one from kdelibs.
Or is there anything speaking against this ?
Yes, my problem with nmake :)
Any news on this?
I tried add_custom_target and it won't work in the automoc macros because
there needs to be a dependency from the main target to the automoc target.
And that cannot be added from the automoc macro because the main target is
not defined at this point.
add_custom_command(TARGET has the same problem.
It would be possible to use add_custom_target and require the user to add
the dependency between the two targets himself. In the KDE4_ macros we
could do that...
Hmmm... then the target will just depend on this target, right ?
So if we had a macro which would be called after the actual target has been
created, like
add_executable(foo ${fooSrcs})
automoc4_target(foo ${fooSrcs})
would that work ?
In KDE we can hide this in the KDE4_ADD_xxx() macros.
automoc itself hasn't been released yet, so there is no problem.
What do you think ?
Will you be at LinuxTag ?
Alex
___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: [ANNOUNCE] automoc4 from kdesupport now supported for building KDE
On Sunday 18 May 2008, Matthias Kretz wrote: automoc4 uses the include directories as specified by include_directory. At least that's what I wrote and expect the code to do. :-) Take a look at the generated target_automoc.cpp.files file. Its second line contains all the include directories as they'll get passed to moc. This line gets generated by the configure_files call in Automoc4.cmake. You mean the line under MOC_INCLUDES? Yes, it contains the path to kdebase/workspace/libs, but this doesn't change the fact that the installed one is taken and not the one from the kdebase source dir. Just lurk a little on #kde-devel and you will see how many run into this problem. Andras -- Quanta Plus developer - http://quanta.kdewebdev.org K Desktop Environment - http://www.kde.org signature.asc Description: This is a digitally signed message part. ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: [ANNOUNCE] automoc4 from kdesupport now supported for building KDE
On Monday 19 May 2008, Andras Mantia wrote: On Sunday 18 May 2008, Matthias Kretz wrote: automoc4 uses the include directories as specified by include_directory. At least that's what I wrote and expect the code to do. :-) Take a look at the generated target_automoc.cpp.files file. Its second line contains all the include directories as they'll get passed to moc. This line gets generated by the configure_files call in Automoc4.cmake. You mean the line under MOC_INCLUDES? Yes, it contains the path to kdebase/workspace/libs, but this doesn't change the fact that the installed one is taken and not the one from the kdebase source dir. My question was not whether it contains that path but whether the order in that file is correct or not. Because that tells you whether the error is in automoc or somewhere else. (i.e. correct order in that file = error in automoc4; incorrect order in the file = error in cmake scripts) Just lurk a little on #kde-devel and you will see how many run into this problem. That doesn't help to find the cause either. -- Matthias Kretz (Germany) http://Vir.homelinux.org/ [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part. ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: [ANNOUNCE] automoc4 from kdesupport now supported for building KDE
On Monday 19 May 2008, Matthias Kretz wrote:
You mean the line under MOC_INCLUDES? Yes, it contains the path to
kdebase/workspace/libs, but this doesn't change the fact that the
installed one is taken and not the one from the kdebase source dir.
My question was not whether it contains that path but whether the
order in that file is correct or not. Because that tells you whether
the error is in automoc or somewhere else. (i.e. correct order in
that file = error in automoc4; incorrect order in the file = error
in cmake scripts)
See here:
MOC_INCLUDES:
/data/development/sources/kde-trunk/kdebase;/data/development/build/kde-
trunk/kdebase;/opt/kde4/include;/opt/kde4/include/KDE;/opt/qt4
/include/phonon;/opt/qt4/include/QtXmlPatterns;/opt/qt4/include/QtWebKit;/opt/qt4/include/QtHelp;/opt/qt4/include/QtAssistant;/opt/qt4
/include/QtDBus;/opt/qt4/include/QtTest;/opt/qt4/include/QtUiTools;/opt/qt4/include/QtScript;/opt/qt4/include/QtSvg;/opt/qt4/include/Q
tXml;/opt/qt4/include/QtSql;/opt/qt4/include/QtOpenGL;/opt/qt4/include/QtNetwork;/opt/qt4/include/QtDesigner;/opt/qt4/include/Qt3Suppo
rt;/opt/qt4/include/QtGui;/opt/qt4/include/QtCore;/opt/qt4/include/Qt;/opt/qt4/mkspecs/default;/opt/qt4/include;/usr/include;/data/dev
elopment/build/kde-
trunk/kdebase/workspace;/data/development/sources/kde-
trunk/kdebase/workspace/kdm;/data/development/sources/kde-tru
nk/kdebase/workspace/libs;/data/development/sources/kde-
trunk/kdebase/workspace/libs/kworkspace;/usr/include/NetworkManager;/usr/inclu
de/glib-2.0;/usr/lib64/glib-2.0/include;/data/development/sources/kde-
trunk/kdebase/workspace/solid/networkmanager-0.7/dbus
So it has both /opt/kde4/include (my trunk installation) and
/usr/include (the system dir where KDE 4.0 is installed) before
/data/development/sources/kde-trunk/kdebase/workspace/libs
(where the updated .h files are and those should be used).
I even modified my CMakeList.txt to have kdebase/workspace/libs as the
first include dir:
include_directories(
${CMAKE_SOURCE_DIR}/workspace/libs
${NETWORKMANAGER_INCLUDE_DIRS}
${NM-UTIL_INCLUDE_DIRS}
${CMAKE_CURRENT_SOURCE_DIR}/dbus
${CMAKE_CURRENT_BUILD_DIR}
)
Just lurk a little on #kde-devel and you will see how many run into
this problem.
That doesn't help to find the cause either.
I was just pointing that this problem is far from being specific to my
system.
Andras
--
Quanta Plus developer - http://quanta.kdewebdev.org
K Desktop Environment - http://www.kde.org
signature.asc
Description: This is a digitally signed message part.
___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: [ANNOUNCE] automoc4 from kdesupport now supported for building KDE
On Sunday 18 May 2008, Matthias Kretz wrote:
automoc4 uses the include directories as specified by include_directory.
Then it has to honour set(CMAKE_INCLUDE_CURRENT_DIR ON) too (as done by
KDE4Defaults.cmake), which
adds ${CMAKE_CURRENT_SOURCE_DIR} and ${CMAKE_CURRENT_BINARY} to the list
automatically everywhere.
--
David Faure, [EMAIL PROTECTED], sponsored by Trolltech to work on KDE,
Konqueror (http://www.konqueror.org), and KOffice (http://www.koffice.org).
___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: [ANNOUNCE] automoc4 from kdesupport now supported for building KDE
On Monday 19 May 2008, Matthias Kretz wrote:
On Monday 19 May 2008, Alexander Neundorf wrote:
On Sunday 18 May 2008, Matthias Kretz wrote:
On Saturday 17 May 2008, Andras Mantia wrote:
On Sunday 11 May 2008 00:58:38 Alexander Neundorf wrote:
If you experience any problems with automoc, please let us know at
kde-buildsystem@kde.org (or here).
Here is a problem: kdebase fails to build if there are some older
include/solid/control/ifaces around.
The error is:
cd
/data/development/build/kde-trunk/kdebase/workspace/solid/networkmana
ge r- 0. 7 /opt/kde4/bin/automoc4
/data/development/build/kde-trunk/kdebase/workspace/solid/networkmana
ge r- 0. 7/solid_networkmanager07_automoc.cpp
/data/development/sources/kde-trunk/kdebase/workspace/solid/networkma
na ge r- 0.7
/data/development/build/kde-trunk/kdebase/workspace/solid/networkmana
ge r- 0. 7 /opt/qt4/bin/moc []
Generating
/data/development/build/kde-trunk/kdebase/workspace/solid/networkmana
ge r- 0. 7/networkinterface.moc from
/data/development/sources/kde-trunk/kdebase/workspace/solid/networkma
na ge r- 0.7/networkinterface.h
/data/development/sources/kde-trunk/kdebase/workspace/solid/networkma
na ge r- 0.7/manager.h:35: Error: Undefined interface
[...]
automoc4: process
for
/data/development/build/kde-trunk/kdebase/workspace/solid/networkmana
ge r- 0. 7/manager.moc failed: Unknown error
pid to wait for: 0
processes in queue: 11
The problem is this line in manager.h:
#include solid/control/ifaces/networkmanager.h
This picks up the installed networkmanager.h instead of the one from
kdebase/workspace/libs/solid/control/ifaces .
I tried to add
${CMAKE_SOURCE_DIR}/workspace/libs
to the include_directories, but seems that this is ignored or
searched after the system path.
So the solution to build kdebase is to remove your installed version
and build again.This also does not work if e.g you have KDE 4.0.x
installed in /usr like it is on openSUSE. So you have to:
- remove the old files (e.g from /opt/kde4/include if KDE trunk was
installed there)
- build AND install kdebase/workspace/libs/solid (so the correct
headers are installed to /opt/kde4)
- build now kdebase/workspace/solid
I find this behavior broken, automoc4 should find the header files
that are in kdebase/workspace/libs/solid/control/ifaces as specified
by the include_directory command.
automoc4 uses the include directories as specified by
include_directory. At least that's what I wrote and expect the code to
do. :-)
Take a look at the generated target_automoc.cpp.files file. Its
second line contains all the include directories as they'll get passed
to moc. This line gets generated by the configure_files call in
Automoc4.cmake.
CMake sorts the include dirs internally, so that in-project include dirs
are always before out-of-project include dirs.
(if CMAKE_INCLUDE_DIRECTORIES_PROJECT_BEFORE is true, done in
kdelibs/cmake/modules/KDE4Defaults.cmake)
Maybe this has to be added for automoc ?
Alex, could you take a look at this please? Automoc4Config.cmake uses
get_directory_property(_moc_incs INCLUDE_DIRECTORIES)
as the ordered include paths to pass to moc. Why does this not work? Or why
does this not work only in kdebase/workspace/solid/ ?
Testcase:
#enable/disable this line and see what happens
set(CMAKE_INCLUDE_DIRECTORIES_PROJECT_BEFORE ON)
include_directories(/opt/qt-copy/include /home/alex/src/tests/incdirtest2)
get_directory_property(incDirs INCLUDE_DIRECTORIES)
message(STATUS inc: ${incDirs})
add_executable(hello main.c)
GET_DIRECTORY_PROPERTY() returns the include dirs as they are, if
CMAKE_INCLUDE_DIRECTORIES_PROJECT_BEFORE is on they are ordered later on, but
that result isn't available.
So, automoc should also get ${CMAKE_INCLUDE_DIRECTORIES_PROJECT_BEFORE} and if
it is true, at first put all include dirs which are subdirs of the build dir,
then all include dirs which are subdirs of the source dir and finally all
other include dirs.
Alex
___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: [ANNOUNCE] automoc4 from kdesupport now supported for building KDE
On Saturday 17 May 2008, Andras Mantia wrote:
On Sunday 11 May 2008 00:58:38 Alexander Neundorf wrote:
If you experience any problems with automoc, please let us know at
kde-buildsystem@kde.org (or here).
Here is a problem: kdebase fails to build if there are some older
include/solid/control/ifaces around.
The error is:
cd
/data/development/build/kde-trunk/kdebase/workspace/solid/networkmanager-0.
7 /opt/kde4/bin/automoc4
/data/development/build/kde-trunk/kdebase/workspace/solid/networkmanager-0.
7/solid_networkmanager07_automoc.cpp
/data/development/sources/kde-trunk/kdebase/workspace/solid/networkmanager-
0.7
/data/development/build/kde-trunk/kdebase/workspace/solid/networkmanager-0.
7 /opt/qt4/bin/moc []
Generating
/data/development/build/kde-trunk/kdebase/workspace/solid/networkmanager-0.
7/networkinterface.moc from
/data/development/sources/kde-trunk/kdebase/workspace/solid/networkmanager-
0.7/networkinterface.h
/data/development/sources/kde-trunk/kdebase/workspace/solid/networkmanager-
0.7/manager.h:35: Error: Undefined interface
[...]
automoc4: process
for
/data/development/build/kde-trunk/kdebase/workspace/solid/networkmanager-0.
7/manager.moc failed: Unknown error
pid to wait for: 0
processes in queue: 11
The problem is this line in manager.h:
#include solid/control/ifaces/networkmanager.h
This picks up the installed networkmanager.h instead of the one from
kdebase/workspace/libs/solid/control/ifaces .
I tried to add
${CMAKE_SOURCE_DIR}/workspace/libs
to the include_directories, but seems that this is ignored or searched
after the system path.
So the solution to build kdebase is to remove your installed version and
build again.This also does not work if e.g you have KDE 4.0.x installed in
/usr like it is on openSUSE. So you have to:
- remove the old files (e.g from /opt/kde4/include if KDE trunk was
installed there)
- build AND install kdebase/workspace/libs/solid (so the correct headers
are installed to /opt/kde4)
- build now kdebase/workspace/solid
I find this behavior broken, automoc4 should find the header files that are
in kdebase/workspace/libs/solid/control/ifaces as specified by the
include_directory command.
automoc4 uses the include directories as specified by include_directory. At
least that's what I wrote and expect the code to do. :-)
Take a look at the generated target_automoc.cpp.files file. Its second line
contains all the include directories as they'll get passed to moc. This line
gets generated by the configure_files call in Automoc4.cmake.
--
Matthias Kretz (Germany)
http://Vir.homelinux.org/
[EMAIL PROTECTED], [EMAIL PROTECTED],
[EMAIL PROTECTED]
signature.asc
Description: This is a digitally signed message part.
___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: [ANNOUNCE] automoc4 from kdesupport now supported for building KDE
On Sunday 11 May 2008 00:58:38 Alexander Neundorf wrote:
If you experience any problems with automoc, please let us know at
kde-buildsystem@kde.org (or here).
Here is a problem: kdebase fails to build if there are some older
include/solid/control/ifaces around.
The error is:
cd /data/development/build/kde-trunk/kdebase/workspace/solid/networkmanager-0.7
/opt/kde4/bin/automoc4
/data/development/build/kde-trunk/kdebase/workspace/solid/networkmanager-0.7/solid_networkmanager07_automoc.cpp
/data/development/sources/kde-trunk/kdebase/workspace/solid/networkmanager-0.7
/data/development/build/kde-trunk/kdebase/workspace/solid/networkmanager-0.7
/opt/qt4/bin/moc
[]
Generating
/data/development/build/kde-trunk/kdebase/workspace/solid/networkmanager-0.7/networkinterface.moc
from
/data/development/sources/kde-trunk/kdebase/workspace/solid/networkmanager-0.7/networkinterface.h
/data/development/sources/kde-trunk/kdebase/workspace/solid/networkmanager-0.7/manager.h:35:
Error: Undefined interface
[...]
automoc4: process
for
/data/development/build/kde-trunk/kdebase/workspace/solid/networkmanager-0.7/manager.moc
failed: Unknown error
pid to wait for: 0
processes in queue: 11
The problem is this line in manager.h:
#include solid/control/ifaces/networkmanager.h
This picks up the installed networkmanager.h instead of the one from
kdebase/workspace/libs/solid/control/ifaces .
I tried to add
${CMAKE_SOURCE_DIR}/workspace/libs
to the include_directories, but seems that this is ignored or searched after
the system path.
So the solution to build kdebase is to remove your installed version and build
again.This also does not work if e.g you have KDE 4.0.x installed in /usr
like it is on openSUSE. So you have to:
- remove the old files (e.g from /opt/kde4/include if KDE trunk was installed
there)
- build AND install kdebase/workspace/libs/solid (so the correct headers are
installed to /opt/kde4)
- build now kdebase/workspace/solid
I find this behavior broken, automoc4 should find the header files that are in
kdebase/workspace/libs/solid/control/ifaces as specified by the
include_directory command.
Andras
--
Quanta Plus developer - http://quanta.kdewebdev.org
K Desktop Environment - http://www.kde.org
___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: automoc4
On Saturday 10 May 2008, Andras Mantia wrote: On Thursday 08 May 2008, Alexander Neundorf wrote: Hmm, I think it shouldn't matter for the Config.cmake file. But it looks ugly and weird to have only this in lib instead of lib64. If you have cmake 2.6.0, put the Automoc4Config.cmake file e.g. into /usr/lib/..., and then create a CMakeLists.txt which just contains find_package(Automoc4) This should find the file automatically (if not check with strace). Please let me know how it works. So how should I test automoc4? Do I need to clean the build dir of kde* modules and rebuild everything? And if it builds, it is ok? Do you mean testing if it is found automatically ? Create a new dir, put a CMakeLists.txt in it: 888 find_package(Automoc4) 888 Then run cmake 2.6 on it. If automoc4 is found, everything is fine. If it is installed in one of the standard dirs like /usr/local/lib, this will just work. If it is e.g. in /opt/kde4/lib/, set the environment variable CMAKE_PREFIX_PATH to /opt/kde4 before running cmake, then it should also be found. Alex ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: automoc4
On Saturday 10 May 2008, Alexander Neundorf wrote: Do you mean testing if it is found automatically ? I mean if it is found by the rest of KDE. I build and install everything into /opt/kde4, including kdesupport. The question is if I need to clear the build dir/install dir prior to testing, or not. Now it works (I can build kde trunk), but I did not clear the build dirs, as a full rebuild takes some time. :) Andras -- Quanta Plus developer - http://quanta.kdewebdev.org K Desktop Environment - http://www.kde.org signature.asc Description: This is a digitally signed message part. ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: automoc4
On Thursday 08 May 2008, Alexander Neundorf wrote: Patch attached (automoc.patch): I'm all for committing this. If you consider it ok, feel free to commit. Will do. I'm using this with the other patch against kdelibs/cmake - which makes the rest of KDE use the automoc from kdesupport. I want to have a look at that in the next day. Actually we must not remove anything from FindKDE4Internal.cmake (as e.g. KDE4_AUTOMOC), since this breaks source compatiblity. I'm not sure about the KDE4_SET/GET_TARGET_PROPERTY(), I don't think anybody else uses them. But anyway, I want to see if I can make it so that automoc4 is optional for a few weeks and if it's not found the one from kdelibs is used. This way developers will have more time to update. So please don't commit this one yet. Yes, I considered my patch good enough for testing, not more. I considered the removal of KDE4_AUTOMOC_EXECUTABLE from FindKDE4Internal.cmake as a change of internals. Sure, everything is accessible to others since this file is installed, but I would expect nobody to use that specific variable other than with the macros in KDE4Macros.cmake. And since FindKDE4Internal and KDE4Macros go together, if the latter stops using KDE4_AUTOMOC_EXECUTABLE, the former should be free to remove the check. IMHO. Same for KDE4_SET/GET_TARGET_PROPERTY(), that's an internal macro and I think I didn't document it either. I think it can be removed. Perhaps there needs to be some policy to mark macros as internal or compatibility will be kept. For now nothing seems to be internal. -- Matthias Kretz (Germany) http://Vir.homelinux.org/ [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part. ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: automoc4
On Thursday 08 May 2008, Matthias Kretz wrote: On Thursday 08 May 2008, Alexander Neundorf wrote: ... I want to have a look at that in the next day. Actually we must not remove anything from FindKDE4Internal.cmake (as e.g. KDE4_AUTOMOC), since this breaks source compatiblity. I'm not sure about the KDE4_SET/GET_TARGET_PROPERTY(), I don't think anybody else uses them. But anyway, I want to see if I can make it so that automoc4 is optional for a few weeks and if it's not found the one from kdelibs is used. This way developers will have more time to update. So please don't commit this one yet. Yes, I considered my patch good enough for testing, not more. Ok. I considered the removal of KDE4_AUTOMOC_EXECUTABLE from FindKDE4Internal.cmake as a change of internals. Sure, everything is accessible to others since this file is installed, but I would expect nobody to use that specific variable other than with the macros in KDE4Macros.cmake. And since FindKDE4Internal and KDE4Macros go together, if the latter stops using KDE4_AUTOMOC_EXECUTABLE, the former should be free to remove the check. IMHO. Well, it's not that much different from removing a function from some header file. Same for KDE4_SET/GET_TARGET_PROPERTY(), that's an internal macro and I think I didn't document it either. I think it can be removed. Although feeling bad about this, I'll think we'll try it for these two macros... Perhaps there needs to be some policy to mark macros as internal or compatibility will be kept. For now nothing seems to be internal. Yes, I'd suggest prefixing internal stuff with an underscore, everything else (which is documented) is public interface. Alex ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: automoc4
On Thursday 08 May 2008, Matthias Kretz wrote: On Wednesday 07 May 2008, Alexander Neundorf wrote: On Tuesday 06 May 2008, Dirk Mueller wrote: On Tuesday 29 April 2008, Alexander Neundorf wrote: Matthias: if we want to keep the option to get it at some point into cmake, we (you) need to relicense it to BSD. Can you do that ? can we add a version number and make a formal release of it? Yes, we should add a version number. 1.0 ? You already added the 1.0 in automoc --version. I'm fine with that version number. :-) On releases: let's give my last change a week or two of general testing and then it'd be great to have a release. Sure :-) Oh, and what about FindAutomoc4.cmake? Currently it only exists in kdesupport/akonadi/cmake/modules... This will of course also be in kdelibs then. Alex ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: automoc4
On Thursday 08 May 2008, Alexander Neundorf wrote: Oh, and what about FindAutomoc4.cmake? Currently it only exists in kdesupport/akonadi/cmake/modules... This will of course also be in kdelibs then. I thought it could perhaps ship with automoc4 itself. That would then be the one and only true source for this file (instead of having copies in all the places that use cmake+automoc but not kdelibs) -- Matthias Kretz (Germany) http://Vir.homelinux.org/ [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part. ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: automoc4
On Tuesday 06 May 2008, Matthias Kretz wrote: On Friday 02 May 2008, Matthias Kretz wrote: On Wednesday 30 April 2008, Alexander Neundorf wrote: Von: Matthias Kretz [EMAIL PROTECTED] On Tuesday 29 April 2008, Alexander Neundorf wrote: Is there an easy way to enforce rerunning automoc ? Would it be possible to add a command line switch which does that ? Like e.g. deleting all generated moc files or something like that ? Alternatives: 1. add a new target (I'd like to avoid that because it would add a lot of I/O on a cmake run) 2. make it easy to run automoc4 manually Yes, something like automoc4 --clean or something like this which does that for the current dir and maybe all subdirs would be nice to have. How about the following: - automoc, when done, writes an empty file target_automoc.notclean - SET_DIRECTORY_PROPERTIES(PROPERTIES ADDITIONAL_MAKE_CLEAN_FILES target_automoc.notclean) - automoc will recreate all moc files if the target_automoc.notclean file is not present (else it will work as it does now) = after a make clean, running make which executes automoc will recreate all moc files. This would again need automoc to be called unconditionally (which I still believe would be good to do - and the touch can be done by automoc itself, which would be portable). Patch attached (automoc.patch): I'm all for committing this. If you consider it ok, feel free to commit. I'm using this with the other patch against kdelibs/cmake - which makes the rest of KDE use the automoc from kdesupport. I want to have a look at that in the next day. Actually we must not remove anything from FindKDE4Internal.cmake (as e.g. KDE4_AUTOMOC), since this breaks source compatiblity. I'm not sure about the KDE4_SET/GET_TARGET_PROPERTY(), I don't think anybody else uses them. But anyway, I want to see if I can make it so that automoc4 is optional for a few weeks and if it's not found the one from kdelibs is used. This way developers will have more time to update. So please don't commit this one yet. Alex ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: automoc4
On Tuesday 29 April 2008, Alexander Neundorf wrote: Matthias: if we want to keep the option to get it at some point into cmake, we (you) need to relicense it to BSD. Can you do that ? can we add a version number and make a formal release of it? I can do the tarballing and uploading etc if nobody else wants. Thanks, Dirk ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: automoc4
On Wednesday 30 April 2008, Alexander Neundorf wrote: Von: Matthias Kretz [EMAIL PROTECTED] On Tuesday 29 April 2008, Alexander Neundorf wrote: Is there an easy way to enforce rerunning automoc ? Would it be possible to add a command line switch which does that ? Like e.g. deleting all generated moc files or something like that ? Alternatives: 1. add a new target (I'd like to avoid that because it would add a lot of I/O on a cmake run) 2. make it easy to run automoc4 manually Yes, something like automoc4 --clean or something like this which does that for the current dir and maybe all subdirs would be nice to have. How about the following: - automoc, when done, writes an empty file target_automoc.notclean - SET_DIRECTORY_PROPERTIES(PROPERTIES ADDITIONAL_MAKE_CLEAN_FILES target_automoc.notclean) - automoc will recreate all moc files if the target_automoc.notclean file is not present (else it will work as it does now) = after a make clean, running make which executes automoc will recreate all moc files. This would again need automoc to be called unconditionally (which I still believe would be good to do - and the touch can be done by automoc itself, which would be portable). -- Matthias Kretz (Germany) http://Vir.homelinux.org/ [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part. ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: automoc4
Original-Nachricht Von: Matthias Kretz [EMAIL PROTECTED] On Tuesday 29 April 2008, Alexander Neundorf wrote: I think we have to do some things now: -write at least some documentation: a page on techbase ? What should be documented? How to use it? How it works? How it breaks? Ideally all of that :-) Matthias: if we want to keep the option to get it at some point into cmake, we (you) need to relicense it to BSD. Can you do that ? done. Cool :-) Is there an easy way to enforce rerunning automoc ? Would it be possible to add a command line switch which does that ? Like e.g. deleting all generated moc files or something like that ? There are two steps of dependency checks: 1. in the Makefile: running automoc depends on the header, source and the target_automoc.files files. 2. when automoc runs it checks for the timestamps of the moc source and moc output file and only calls moc if the source is more recent. To regenerate all mocs one must either touch all source files or touch the target_automoc.files file and delete all .moc files. Deleting all .moc files is a bit problematic since cmake might have created a dependecy on those files but didn't write into the Makefile how the .moc files are created. Alternatives: 1. add a new target (I'd like to avoid that because it would add a lot of I/O on a cmake run) 2. make it easy to run automoc4 manually Yes, something like automoc4 --clean or something like this which does that for the current dir and maybe all subdirs would be nice to have. Alex -- Psst! Geheimtipp: Online Games kostenlos spielen bei den GMX Free Games! http://games.entertainment.gmx.net/de/entertainment/games/free ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
automoc4
Hi, now that automoc4 is in kdesupport and used by akonadi, I think we'll enable it next week or so also for the rest of KDE (with a transition period where the one from kdelibs is still used if automoc4 is not found). I think we have to do some things now: -write at least some documentation: a page on techbase ? Matthias: if we want to keep the option to get it at some point into cmake, we (you) need to relicense it to BSD. Can you do that ? Is there an easy way to enforce rerunning automoc ? Would it be possible to add a command line switch which does that ? Like e.g. deleting all generated moc files or something like that ? Alex ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
