[kde] Re: Building DBusMenu-Qt
> Ok, I found these in the cmake and set them to OFF: > WITH_PolkitQt OFF > WITH_PolkitQt-1 OFF > > I also found these: > KDE4_AUTH_BACKEND_NAME FAKE > KDE4_AUTH_HELPER_BACKEND_NAME DBUS > > I lookd in: kdecore/auth/ConfigureChecks.cmake and it said I could set > KDE4_AUTH_BACKEND_NAME to empty and it would find the best option. I > guess 'FAKE' was the best option, because it keeps changing back to > that, and it still won't fniish configuring, it quits with "No valid > KAuth backends will be built. The library will not work properly > unless compiled". > > Any more ideas of how to turn this off? > > David > Just a follow up - this was indeed only a warning. There were other errors that were below the end of the page in ccmake that I did not see. David ___ This message is from the kde mailing list. Account management: https://mail.kde.org/mailman/listinfo/kde. Archives: http://lists.kde.org/. More info: http://www.kde.org/faq.html.
[kde] Re: Building DBusMenu-Qt
On Mon, Jun 20, 2011 at 5:49 PM, Duncan <1i5t5.dun...@cox.net> wrote: > David Doria posted on Mon, 20 Jun 2011 15:18:59 -0400 as excerpted: > >>> OK, try setting/exporting QMAKESPEC > >> Great, that worked (I did need the subdir: >> /home/ddoria/bin/qt4/mkspecs/linux-g++-64)! >> >> Since then, I have been able to build automoc and phonon. > > Good, you're getting into kde-recognizable technologies, now. =:^) > >> Now again trying to build kdelibs, I am getting: >> >> WARNING: No valid KAuth backends will be built. The library will not >> work properly unless compiled with a working backend >> >> It seems more like an error than a warning, because after running cmake >> configure several times I still don't get the option to 'generate'. >> >> It looks like I may need to build polkit? When trying to do that, my >> autoconf was too old! I built autoconf, and then when I configured >> polkit, it said I am missing gio2.0. I can't find where to download gio >> source - can you please point me to it? > > Based on the dependencies here, you should be able to specify that you do > NOT want polkit support, since Gentoo has it as a USE flag which means > the dependency is optional. Let me see how the build specifies that it > wants it or not... > > $(cmake-utils_use_with policykit PolkitQt-1) > > Translating the gentoo eclass shorthand... > > cmake-utils_use_with [flag name] > `cmake-utils_use_with foo FOO` echoes -DWITH_FOO=ON if foo is enabled > and -DWITH_FOO=OFF if it is disabled. > > (That's from the gentoo cmake-utils.eclass manpage, auto-generated from > in-eclass documentation.) > > So -DWITH_PolkitQt-1=OFF fed to the ./configure step, should disable that > dependency. (You can probably run ./configure --help to get a listing of > this and other options you can feed to configure. Might come in handy > for other dependencies...) > > As for gio2.0, I don't see a direct dependency of that name, but based on > some comments on plugin packages for it, I /believe/ it's part of glib. > So you apparently need a newer glib. 2.28.8 is what I have installed, > 2.28.6 is also available in gentoo, as well as the old glib-1.2.10 for > those apps still using glib-1. The polkit-0.101 ebuild says it needs >>=glib-2.28, with the gentoo changelog saying 2.28.0 was introduced in > February. (Note that if you build a new glib, you'll probably need to > rebuild dbus-glib too, as it'll break with a new glib.) > > But depending on why you are building kdelibs (I thought I saw that you > wanted it for kdevelop, but I can't seem to find it now), if you don't > think you'll need the auth framework, it's probably easiest to simply > disable that... at the cost of possibly needing to go back and enable it > because something doesn't work, later. If you're building all of kde, > I'd definitely recommend keeping it enabled, but if you're just doing it > for a couple packages, that aren't likely to need superuser auth or the > like, you can probably get by without it. > > -- > Duncan - List replies preferred. No HTML msgs. Ok, I found these in the cmake and set them to OFF: WITH_PolkitQtOFF WITH_PolkitQt-1 OFF I also found these: KDE4_AUTH_BACKEND_NAME FAKE KDE4_AUTH_HELPER_BACKEND_NAMEDBUS I lookd in: kdecore/auth/ConfigureChecks.cmake and it said I could set KDE4_AUTH_BACKEND_NAME to empty and it would find the best option. I guess 'FAKE' was the best option, because it keeps changing back to that, and it still won't fniish configuring, it quits with "No valid KAuth backends will be built. The library will not work properly unless compiled". Any more ideas of how to turn this off? David ___ This message is from the kde mailing list. Account management: https://mail.kde.org/mailman/listinfo/kde. Archives: http://lists.kde.org/. More info: http://www.kde.org/faq.html.
[kde] Re: Building DBusMenu-Qt
David Doria posted on Mon, 20 Jun 2011 15:18:59 -0400 as excerpted: >> OK, try setting/exporting QMAKESPEC > Great, that worked (I did need the subdir: > /home/ddoria/bin/qt4/mkspecs/linux-g++-64)! > > Since then, I have been able to build automoc and phonon. Good, you're getting into kde-recognizable technologies, now. =:^) > Now again trying to build kdelibs, I am getting: > > WARNING: No valid KAuth backends will be built. The library will not > work properly unless compiled with a working backend > > It seems more like an error than a warning, because after running cmake > configure several times I still don't get the option to 'generate'. > > It looks like I may need to build polkit? When trying to do that, my > autoconf was too old! I built autoconf, and then when I configured > polkit, it said I am missing gio2.0. I can't find where to download gio > source - can you please point me to it? Based on the dependencies here, you should be able to specify that you do NOT want polkit support, since Gentoo has it as a USE flag which means the dependency is optional. Let me see how the build specifies that it wants it or not... $(cmake-utils_use_with policykit PolkitQt-1) Translating the gentoo eclass shorthand... cmake-utils_use_with [flag name] `cmake-utils_use_with foo FOO` echoes -DWITH_FOO=ON if foo is enabled and -DWITH_FOO=OFF if it is disabled. (That's from the gentoo cmake-utils.eclass manpage, auto-generated from in-eclass documentation.) So -DWITH_PolkitQt-1=OFF fed to the ./configure step, should disable that dependency. (You can probably run ./configure --help to get a listing of this and other options you can feed to configure. Might come in handy for other dependencies...) As for gio2.0, I don't see a direct dependency of that name, but based on some comments on plugin packages for it, I /believe/ it's part of glib. So you apparently need a newer glib. 2.28.8 is what I have installed, 2.28.6 is also available in gentoo, as well as the old glib-1.2.10 for those apps still using glib-1. The polkit-0.101 ebuild says it needs >=glib-2.28, with the gentoo changelog saying 2.28.0 was introduced in February. (Note that if you build a new glib, you'll probably need to rebuild dbus-glib too, as it'll break with a new glib.) But depending on why you are building kdelibs (I thought I saw that you wanted it for kdevelop, but I can't seem to find it now), if you don't think you'll need the auth framework, it's probably easiest to simply disable that... at the cost of possibly needing to go back and enable it because something doesn't work, later. If you're building all of kde, I'd definitely recommend keeping it enabled, but if you're just doing it for a couple packages, that aren't likely to need superuser auth or the like, you can probably get by without it. -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman ___ This message is from the kde mailing list. Account management: https://mail.kde.org/mailman/listinfo/kde. Archives: http://lists.kde.org/. More info: http://www.kde.org/faq.html.
[kde] Re: Building DBusMenu-Qt
> OK, try setting/exporting QMAKESPEC, pointing at the desire directory, > probably /home/ddoria/bin/qt4/mkspecs/ but I'm not sure if you'll need > the platform triplet subdir on the end of that or if it'll figure that > out itself. Try it both ways. (I'm not sure that'll work as I'm > actually basing that on an unset in the qt-core build, but it's worth a > shot.) Great, that worked (I did need the subdir: /home/ddoria/bin/qt4/mkspecs/linux-g++-64)! Since then, I have been able to build automoc and phonon. Now again trying to build kdelibs, I am getting: WARNING: No valid KAuth backends will be built. The library will not work properly unless compiled with a working backend It seems more like an error than a warning, because after running cmake configure several times I still don't get the option to 'generate'. It looks like I may need to build polkit? When trying to do that, my autoconf was too old! I built autoconf, and then when I configured polkit, it said I am missing gio2.0. I can't find where to download gio source - can you please point me to it? As you said, we're getting there... :) David ___ This message is from the kde mailing list. Account management: https://mail.kde.org/mailman/listinfo/kde. Archives: http://lists.kde.org/. More info: http://www.kde.org/faq.html.
[kde] Re: Building DBusMenu-Qt
David Doria posted on Mon, 20 Jun 2011 09:46:28 -0400 as excerpted: > On Sat, Jun 18, 2011 at 12:36 AM, Duncan <1i5t5.dun...@cox.net> wrote: >> David Doria posted on Fri, 17 Jun 2011 22:28:59 -0400 as excerpted: >> >>> I am on RHEL 5.6 which has super old packages of everything. >> >> 5.6. Yeah, that'd be older packages, for sure. > I don't know what I did differently, but the xml2cpp and cpp2xml were > built this time around. This allowed me to build dbusmenu-qt. =:^) > So now I am back to trying to build kdelibs. > > CMake is telling me: > > CMake Warning at cmake/modules/FindQt4.cmake:437 (MESSAGE): > querying qmake for QMAKE_LIBS_OPENGL. qmake reported: > >Failure to read QMAKESPEC conf file >/home/ddoria/build/mkspecs/linux-g++-64/qmake.conf. > >Error processing project file: >/home/ddoria/build/kdelibs/CMakeFiles/CMakeTmpQmake/tmp.pro > > I don't think this makes sense, as > /home/ddoria/build/mkspecs/linux-g++-64/qmake.conf is certainly not a > directory. However, the file > /home/ddoria/bin/qt4/mkspecs/linux-g++-64/qmake.conf does indeed exist. You're misreading the warning. It's looking in the *file* .../linux-g++-64/qmake.conf, for the *setting* QMAKE_LIBS_OPENGL. (Hmm, are you sure that's not QMAKE_LIBDIR_OPENGL?. That's the setting in the file I have here?) It's looking in the wrong place (build instead of bin) for the file, so it's not finding it. FWIW, I made the mistake of equerying portage for the package containing qmake.conf, presuming it was one of the qt split-packages, but what I was really wanting was the location, since it would show me where it placed it as part of the answer. I didn't realize there's about 50 such files, all part of qt-core! =:^) After reformulating my query... That linux-g++-64 bit is a qt-compiler- platform triplet, denoting kernel, compiler, bitness. Qt appears to install, as I said, about 50 qmake.conf files, each covering a different triplet including MS Windows, OSX and various proprietary Unixes in addition to Linux, 32 and 64-bit, and for various compilers. Each one would contain the default settings for that platform. > I have set these variables in my bashrc: > > export PATH=$PATH:/home/ddoria/bin/qt4/bin > export QTDIR=/home/ddoria/bin/qt4 > export QT_QMAKE_EXECUTABLE=/home/ddoria/bin/qt4/bin/qmake > > Any clues where to go from here? Well, the "quick hack" method would be to create a symlink where it's looking, pointing at where you want it to look... I've certainly done such before. But that's definitely a hack. It's probably worth mentioning that you're obviously making progress. You got past the first set of raw dependency issues, now into something quite different, build-time-config issues. Hey, progress is progress! I admire your persistence. This is most certainly a case of dependency hell if I've ever seen one and I'm getting a new appreciation for all that the gentoo ebuild scripts and package manager do for me, but you ARE making progress. Now I have to go looking a bit deeper into the gentoo ebuilds to see what they're doing, here, to try to avoid the hack I mentioned above, which is likely to get you past this bit, only to cause other problems later. Oh, now that I'm looking into the kdelibs ebuild, what compiler are you using? Seems there's a possible issue with gcc-4,3 and earlier for kde 4.6 and later. Gentoo now blocks that with a warning. However, the specific bug says kdegames which I'd guess wouldn't be an issue for you. However, with that blocker, they're now going to miss any other such bugs. So you'll hopefully be OK with an earlier gcc, but there's a possibility you'll need at least gcc 4.4. FWIW, the bug mentioned is here (gentoo bug with an upstream kde bug reference): http://bugs.gentoo.org/show_bug.cgi?id=354837 OK, try setting/exporting QMAKESPEC, pointing at the desire directory, probably /home/ddoria/bin/qt4/mkspecs/ but I'm not sure if you'll need the platform triplet subdir on the end of that or if it'll figure that out itself. Try it both ways. (I'm not sure that'll work as I'm actually basing that on an unset in the qt-core build, but it's worth a shot.) If that doesn't work, I'll have to look into the ebuild scripts further, but I'm getting too sleepy to make sense of them ATM and want to send this before I go to bed, so... -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman ___ This message is from the kde mailing list. Account management: https://mail.kde.org/mailman/listinfo/kde. Archives: http://lists.kde.org/. More info: http://www.kde.org/faq.html.
[kde] Re: Building DBusMenu-Qt
On Sat, Jun 18, 2011 at 12:36 AM, Duncan <1i5t5.dun...@cox.net> wrote: > David Doria posted on Fri, 17 Jun 2011 22:28:59 -0400 as excerpted: > >> I am on RHEL 5.6 which has super old packages of everything. I have >> therefore built Qt from source and am building kdelibs from source. So >> my question is more of "why did qdbusxml2cpp not get built when I built >> Qt?". Is there a way to "enable everything" or something like that? I'm >> so used to cmake now-a-days that I don't know how to set options like >> that without it! > > 5.6. Yeah, that'd be older packages, for sure. > > Why didn't qdbusxml2cpp get built with qt? I don't know as the gentoo > build-scripts have always taken care of that for me. > > Are you sure it did /not/ get built? Here, it's in /usr/bin, but > presumably it'd be in /usr/local/bin or the like if you didn't specify a > location for it. I don't know what I did differently, but the xml2cpp and cpp2xml were built this time around. This allowed me to build dbusmenu-qt. So now I am back to trying to build kdelibs. CMake is telling me: CMake Warning at cmake/modules/FindQt4.cmake:437 (MESSAGE): querying qmake for QMAKE_LIBS_OPENGL. qmake reported: Failure to read QMAKESPEC conf file /home/ddoria/build/mkspecs/linux-g++-64/qmake.conf. Error processing project file: /home/ddoria/build/kdelibs/CMakeFiles/CMakeTmpQmake/tmp.pro I don't think this makes sense, as /home/ddoria/build/mkspecs/linux-g++-64/qmake.conf is certainly not a directory. However, the file /home/ddoria/bin/qt4/mkspecs/linux-g++-64/qmake.conf does indeed exist. I have set these variables in my bashrc: export PATH=$PATH:/home/ddoria/bin/qt4/bin export QTDIR=/home/ddoria/bin/qt4 export QT_QMAKE_EXECUTABLE=/home/ddoria/bin/qt4/bin/qmake Any clues where to go from here? Thanks, David ___ This message is from the kde mailing list. Account management: https://mail.kde.org/mailman/listinfo/kde. Archives: http://lists.kde.org/. More info: http://www.kde.org/faq.html.
[kde] Re: Building DBusMenu-Qt
David Doria posted on Fri, 17 Jun 2011 22:28:59 -0400 as excerpted: > I am on RHEL 5.6 which has super old packages of everything. I have > therefore built Qt from source and am building kdelibs from source. So > my question is more of "why did qdbusxml2cpp not get built when I built > Qt?". Is there a way to "enable everything" or something like that? I'm > so used to cmake now-a-days that I don't know how to set options like > that without it! 5.6. Yeah, that'd be older packages, for sure. Why didn't qdbusxml2cpp get built with qt? I don't know as the gentoo build-scripts have always taken care of that for me. Are you sure it did /not/ get built? Here, it's in /usr/bin, but presumably it'd be in /usr/local/bin or the like if you didn't specify a location for it. Maybe your dbus is too old? Let's see what the deps look like for it. I have dbus-1.4.12 installed. The qt-dbus ebuild requires >=dbus-1.0.2. Gentoo's dbus versions go back only thru 1.4.6, which was introduced only in February of this year. dbus-1.0.2 appears to have been introduced in Gentoo back in Dec of 2006 and removed in July of 2009. Meanwhile, the configure logs spit this out when testing for dbus: D-Bus auto-detection... () And the summary at the end of the configure step includes this: QtDBus module .. yes (linked) So try searching/grepping for that in your qt build log and see what turns up. (Or if that's gone, you can just run thru the configure step and see what it spits out. That's what I just did here as I only keep ~4 weeks of build-log rotation and qt-4.7.3 was installed ~5-6 weeks ago.) -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman ___ This message is from the kde mailing list. Account management: https://mail.kde.org/mailman/listinfo/kde. Archives: http://lists.kde.org/. More info: http://www.kde.org/faq.html.
[kde] Re: Building DBusMenu-Qt
> I believe the executable you are looking for is qdbusxml2cpp, which is > part of the package (on gentoo) qt-dbus, which in turn is a part of qt, > split-packaged on gentoo as qt-core, qt-dbus, qt-declarative... and a > bunch of others. > > So you either need qt installed, or a newer version installed, or to tell > cmake where to find it, I don't know which. I am on RHEL 5.6 which has super old packages of everything. I have therefore built Qt from source and am building kdelibs from source. So my question is more of "why did qdbusxml2cpp not get built when I built Qt?". Is there a way to "enable everything" or something like that? I'm so used to cmake now-a-days that I don't know how to set options like that without it! David ___ This message is from the kde mailing list. Account management: https://mail.kde.org/mailman/listinfo/kde. Archives: http://lists.kde.org/. More info: http://www.kde.org/faq.html.
[kde] Re: Building DBusMenu-Qt
David Doria posted on Fri, 17 Jun 2011 17:25:04 -0400 as excerpted: > Following the instructions here: > http://techbase.kde.org/Getting_Started/Build/Qt#DBusMenu-Qt > > I cloned DBusMenu-Qt . Then I ran cmake, it says: > > "Please set them or make sure they are set and tested correctly in the > CMake files: > QT_QTDBUS_INCLUDE_DIR (ADVANCED)" > > However, it lets me generate anyway. Then when I run 'make', I get: > > [ 3%] Generating dbusmenuadaptor.cpp, dbusmenuadaptor.h /bin/sh: > QT_DBUSXML2CPP_EXECUTABLE-NOTFOUND: command not found > > I searched for find . -iname *xml2cpp* > in my /home/ddoria/bin/qt4, but it didn't find anything. > > Am I missing something in this process? I believe the executable you are looking for is qdbusxml2cpp, which is part of the package (on gentoo) qt-dbus, which in turn is a part of qt, split-packaged on gentoo as qt-core, qt-dbus, qt-declarative... and a bunch of others. So you either need qt installed, or a newer version installed, or to tell cmake where to find it, I don't know which. FWIW, I have qt-4.7.3 installed here. All available libdbusmenu-qt versions (0.8.2, 0.6.2, and a live-build version I didn't mention earlier, live-builds are fake-versioned on gentoo as for those brave enough to unmask and try them) on gentoo require qt version 4.6.3 minimum. -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman ___ This message is from the kde mailing list. Account management: https://mail.kde.org/mailman/listinfo/kde. Archives: http://lists.kde.org/. More info: http://www.kde.org/faq.html.
