Re: Build errors
On Thursday 30 March 2006 02:49, you wrote: > unresolved external symbol > "__declspec(dllimport) public: bool __thiscall QUrl::hasQuery(void)const That's what the qt-copy patches add. If it's not there, then you didn't apply all the patches, or you didn't rebuild Qt, or it's finding another Qt on your harddisk. -- 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: Build errors
Maarten Th. Mulders schrieb: > Well, rebuild Qt 4.1.1 with the patches you mentioned. Building dcop.exe > now fails with: > > Linking CXX executable ..\..\bin\dcop.exe > dcop.obj : error LNK2019: unresolved external symbol > "__declspec(dllimport) public: bool __thiscall QUrl::hasQuery(void)const > " ([EMAIL PROTECTED]@@QBE_NXZ) > referenced in function "public: class QString __thiscall > KUrl::encodedPathAndQuery(int,bool)const " > ([EMAIL PROTECTED]@@QBE?AVQString@@[EMAIL PROTECTED]) > ..\..\bin\dcop.exe : fatal error LNK1120: 1 unresolved externals > > What did I do wrong? > You did not rebuild qt. Christian signature.asc Description: OpenPGP digital signature ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: Build errors
Paulo Jorge Guedes schrieb: >> -Original Message- >> From: William A. Hoffman [mailto:[EMAIL PROTECTED] >> Sent: quarta-feira, 29 de Março de 2006 15:42 >> To: kde-buildsystem@kde.org >> Subject: Re: Build errors >> >> What is the current status of the windows build? >> Is it time to set up a dashboard? I have not done so >> yet, because it did not compile without errors. Should >> kdelibs compile without errors on windows now? > > I can't test lately as I can't build Qt (from Trolltech) from source: > > $ make > cd src && make -f Makefile > make[1]: Entering directory > `/d/kde/qt-win-opensource-src-4.1.3-snapshot-20060322/src' > make[1]: *** No rule to make target `..\.qmake.cache', needed by `Makefile'. > Stop. > make[1]: Leaving directory > `/d/kde/qt-win-opensource-src-4.1.3-snapshot-20060322/src' > make: *** [sub-src-make_default-ordered] Error 2 > Please inform you about how to compile programs with mingw: ./configure mingw32-make ... Also you must remove all msys/cygwin paths from your PATH environment variable. See qt-interest for qt-compiling problems. Christian signature.asc Description: OpenPGP digital signature ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Build errors
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Well, rebuild Qt 4.1.1 with the patches you mentioned. Building dcop.exe now fails with: Linking CXX executable ..\..\bin\dcop.exe dcop.obj : error LNK2019: unresolved external symbol "__declspec(dllimport) public: bool __thiscall QUrl::hasQuery(void)const " ([EMAIL PROTECTED]@@QBE_NXZ) referenced in function "public: class QString __thiscall KUrl::encodedPathAndQuery(int,bool)const " ([EMAIL PROTECTED]@@QBE?AVQString@@[EMAIL PROTECTED]) ..\..\bin\dcop.exe : fatal error LNK1120: 1 unresolved externals What did I do wrong? Regards, Maarten Th. Mulders On Wednesday 29 March 2006, David Faure wrote: > > You need to apply the patches from trunk/qt-copy/patches to your version of > Qt, for now. > > -- > David Faure, faure at kde.org, sponsored by Trolltech to work on KDE, > Konqueror (http://www.konqueror.org), and KOffice (http://www.koffice.org). - -- The digital signature in this email can be checked with * Thunderbird: the Enigmail-extension (http://enigmail.mozdev.org/) * Outlook (Express): the GnuPG-Plugin (http://www3.gdata.de/gpg/index.html). -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.2 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEKysJrlDGjB4EDkARAvLUAJ0apq3dVxdaHqok193Zogquhl3kWgCfR+NG D1xxQ040Rmm2Un4cCvGQOB8= =n39t -END PGP SIGNATURE- ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: "Please create a separate build directory and run 'cmake path_to_kdelibs [options]' there."
On Thursday 30 March 2006 00:36, Kurt Pfeifle wrote: > On Wednesday 29 March 2006 21:42, Alexander Neundorf wrote: > > On Wednesday 29 March 2006 23:22, Kurt Pfeifle wrote: > > ... > > > > > [EMAIL PROTECTED]:~/src/kde40svn/trunk/KDE/build/kdelibs> echo $(cd > > > ../../kdelibs;pwd) /home/kdev4/src/kde40svn/trunk/KDE/kdelibs > > > > > > [EMAIL PROTECTED]:~/src/kde40svn/trunk/KDE/build/kdelibs> cmake > > > ../../kdelibs -- debug output for Kurt, remove ASAP again: insource -1- > > > \ srcdir: -/home/kdev4/src/kde40svn/trunk/KDE/kdelibs- \ > > > bindir: -/home/kdev4/src/kde40svn/trunk/KDE/kdelibs- > > > > And you really don't have a CMakeCache.txt > > in /home/kdev4/src/kde40svn/trunk/KDE/kdelibs ? > > I had it; timestamp 1 hour ago. Must have been regenerated even after > I had nuked the srcdir. Ok, that's the reason why cmake says /home/kdev4/src/kde40svn/trunk/KDE/kdelibs is the bindir. If a CMakeCache.txt exists, you cannot rerun cmake from another directory without deleting this file first. Bye Alex -- Work: alexander.neundorf AT jenoptik.com - http://www.jenoptik-los.de Home: neundorf AT kde.org- http://www.kde.org alex AT neundorf.net - http://www.neundorf.net ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: "Please create a separate build directory and run 'cmake path_to_kdelibs [options]' there."
On Wednesday 29 March 2006 21:42, Alexander Neundorf wrote: > On Wednesday 29 March 2006 23:22, Kurt Pfeifle wrote: > ... > > [EMAIL PROTECTED]:~/src/kde40svn/trunk/KDE/build/kdelibs> echo $(cd > > ../../kdelibs;pwd) /home/kdev4/src/kde40svn/trunk/KDE/kdelibs > > > > [EMAIL PROTECTED]:~/src/kde40svn/trunk/KDE/build/kdelibs> cmake > > ../../kdelibs -- debug output for Kurt, remove ASAP again: insource -1- \ > > srcdir: -/home/kdev4/src/kde40svn/trunk/KDE/kdelibs- \ > > bindir: -/home/kdev4/src/kde40svn/trunk/KDE/kdelibs- > > And you really don't have a CMakeCache.txt > in /home/kdev4/src/kde40svn/trunk/KDE/kdelibs ? I had it; timestamp 1 hour ago. Must have been regenerated even after I had nuked the srcdir. For tonight I have to give up again; and will likely not have time to revisit the issue within the next 2 weeks. (It seems to hit just me -- maybe it goes away meanwhile.) > Bye > Alex Thanks, Kurt ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: "Please create a separate build directory and run 'cmake path_to_kdelibs [options]' there."
At 04:22 PM 3/29/2006, Kurt Pfeifle wrote: > [EMAIL PROTECTED]:~/src/kde40svn/trunk/KDE/build/kdelibs> hostname -f > nx.openusability.org > > [EMAIL PROTECTED]:~/src/kde40svn/trunk/KDE/build/kdelibs> pwd > /home/kdev4/src/kde40svn/trunk/KDE/build/kdelibs > > [EMAIL PROTECTED]:~/src/kde40svn/trunk/KDE/build/kdelibs> echo $(cd > ../../kdelibs;pwd) > /home/kdev4/src/kde40svn/trunk/KDE/kdelibs > > [EMAIL PROTECTED]:~/src/kde40svn/trunk/KDE/build/kdelibs> cmake ../../kdelibs > -- debug output for Kurt, remove ASAP again: insource -1- \ > srcdir: -/home/kdev4/src/kde40svn/trunk/KDE/kdelibs- \ > bindir: -/home/kdev4/src/kde40svn/trunk/KDE/kdelibs- > > kdelibs requires an out of source build. Please create a separate build > directory \ > and run 'cmake path_to_kdelibs [options]' there. > -- Configuring done How about one more thing: from the directory you are running cmake: ls ../../kdelibs -Bill ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: "Please create a separate build directory and run 'cmake path_to_kdelibs [options]' there."
On Wednesday 29 March 2006 20:34, Tanner Lovelace wrote: > On 3/29/06, Kurt Pfeifle <[EMAIL PROTECTED]> wrote: > > My "cmake path_to_kdelibs" uses a relative path though -- could that > > be an issue? > > No, a relative path there should be completely fine. > > I wonder if there is some sort of limit on the cmake string compare > functions. How long is the full path to your source and build trees? > Here's something you might try. Can you rename your build directory > something like kdelibs-build and rerun cmake? It should not make > a difference, but if the string compare function is getting confused > that should make it work. Indeed it didn't make a difference. But I forgot to consider one thing: I had been running a cmake from SVN (about 2 days old). And in the meanwhile I've read the mailing list advice to rather stay away from this, and instead use specifically recommended tarballs. I didn't follow the advice for now; instead I updated cmake to current CVS and built once more. This didnt make it work either... But perhaps it is a cmake bug in current CVS? I'll use the latest tarball now and try again. > It also might make sense to have the error message print out what it > thinks the source and attempted build directory are. Something like > the patch I have attached. I can add that to the CMakeLists.txt > file if that sounds like a good idea. Thanks for being another caring soul :-) Alex has already done so (see my last posting). > Cheers, > Tanner Cheers, Kurt ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Suggestion to make ccmake even more friendly
Hi, CMake devleopers, I found ccmake a quite good approach to make the configure setup for cmake more "compile newbie"-user friendly. Thank you for that! Here are two suggestions to improve it even further: * It recently happened that I came back to a screen session with 2 "windows" open where I had ccmake open in 2 different builddirs (kdelibs and kdelibs4_snapshot). I could not remember which was which, and couldn't discover any hint in the visible ccmake ncurses window either. --> It would be nice if ccmake would display either the current directory, or the "module" it is called for. (There is some space still underneath "CMake Version" in the lower pane :-) * ccmake displays all "paths" starting with a leading slash (even if they are meant as relative paths). This may be confusing. Examples are: CONFIG_INSTALL_DIR and COVERAGE_COMMAND --> it would be nice if there was a marker that distinguishes absolute and relative paths. Cheers, Kurt ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: "Please create a separate build directory and run 'cmake path_to_kdelibs [options]' there."
On Wednesday 29 March 2006 23:22, Kurt Pfeifle wrote: ... > [EMAIL PROTECTED]:~/src/kde40svn/trunk/KDE/build/kdelibs> echo $(cd > ../../kdelibs;pwd) /home/kdev4/src/kde40svn/trunk/KDE/kdelibs > > [EMAIL PROTECTED]:~/src/kde40svn/trunk/KDE/build/kdelibs> cmake > ../../kdelibs -- debug output for Kurt, remove ASAP again: insource -1- \ > srcdir: -/home/kdev4/src/kde40svn/trunk/KDE/kdelibs- \ > bindir: -/home/kdev4/src/kde40svn/trunk/KDE/kdelibs- And you really don't have a CMakeCache.txt in /home/kdev4/src/kde40svn/trunk/KDE/kdelibs ? Bye Alex -- Work: alexander.neundorf AT jenoptik.com - http://www.jenoptik-los.de Home: neundorf AT kde.org- http://www.kde.org alex AT neundorf.net - http://www.neundorf.net ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: Small build fixes for kdebase/cmake
Hi, On Wednesday 29 March 2006 02:34, Michael Biebl wrote: > Compiling kdebase against kdelibs4_snapshot failed at four places for > me because of missing headers. (Xcursor/Xrender headers were not > found). > I added X11_Xcursor_INCLUDE_PATH/X11_Xrender_INCLUDE_PATH to the > include path for the failing targets to fix this. Please find the > attached patch. > > Cheers, > Michael I think I fixed it, but slightly different. Now the include paths of all the X11 sub-modules are added to X11_INCLUDE_DIR, which is part of KDE4_INCLUDES on UNIX (except OS X). So they should be available everywhere without having to add them manually. Bye Alex -- Work: alexander.neundorf AT jenoptik.com - http://www.jenoptik-los.de Home: neundorf AT kde.org- http://www.kde.org alex AT neundorf.net - http://www.neundorf.net ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: Broken continuous build for KDE dash17.kitware/Linux-Debian-gcc4.1
At 03:31 PM 3/29/2006, David Faure wrote: >=an email sent. The subject line should be different, dash17 or matt.rogers. > >Yes. But I was getting two from dash17 and two from matt.rogers. > >The To line could also be simplified :) I think that should be fixed now. Lets see what happens the next time. -Bill ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: Broken continuous build for KDE dash17.kitware/Linux-Debian-gcc4.1
On Wednesday 29 March 2006 22:22, Bill Hoffman wrote: > At 11:04 AM 3/28/2006, David Faure wrote: > > >Any reason why we get two mails with 10s interval for each failing build, > >BTW? > >The only difference seems to be > >To: [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL > >PROTECTED], [EMAIL PROTECTED] > >in the first one. > > > There are two continuous machines running, each time there is a failure on a > machine there > is an email sent. The subject line should be different, dash17 or > matt.rogers. Yes. But I was getting two from dash17 and two from matt.rogers. The To line could also be simplified :) -- 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: "Please create a separate build directory and run 'cmake path_to_kdelibs [options]' there."
On Wednesday 29 March 2006 20:54, Alexander Neundorf wrote: > On Wednesday 29 March 2006 19:21, Kurt Pfeifle wrote: > > Hi, > > > > today (after a week or so not trying to compile), I get this error: > > > > [EMAIL PROTECTED]:~/KDE/build/kdelibs> cmake ../../kdelibs > > kdelibs requires an out of source build. Please create a separate build \ > >directory and run 'cmake path_to_kdelibs [options]' there. > > -- Configuring done > > > > I wasn't able to follow the list for any changes, so please bear with me if > > I missed some obvious buildchange announcement. > > > > But I'm definitely in (an even virgin) "out of source" build directory. The > > source dir is also freshly checked out (into another virgin directory). > > > > What could be causing this error? A mistake, where someone has erraneously > > committed generated cmake files into SVN? Or something I'm doing wrong on > > my part? > > Please update kdelibs/CMakeLists.txt, I inserted some debug output, so you > see > what cmake considers to be the sourcedir and the builddir. Oh, thanks. This is a very special, caring treatment which I normally do not deserve :-) (but maybe the people deserve this for whom I'm trying to "learn" cmake building so I can help them better in the future). > Maybe you find the problem yourself, otherwise please post the output here. > > (starts with: "debug output for Kurt") Here we go... [EMAIL PROTECTED]:~/src/kde40svn/trunk/KDE/build/kdelibs> hostname -f nx.openusability.org [EMAIL PROTECTED]:~/src/kde40svn/trunk/KDE/build/kdelibs> pwd /home/kdev4/src/kde40svn/trunk/KDE/build/kdelibs [EMAIL PROTECTED]:~/src/kde40svn/trunk/KDE/build/kdelibs> echo $(cd ../../kdelibs;pwd) /home/kdev4/src/kde40svn/trunk/KDE/kdelibs [EMAIL PROTECTED]:~/src/kde40svn/trunk/KDE/build/kdelibs> cmake ../../kdelibs -- debug output for Kurt, remove ASAP again: insource -1- \ srcdir: -/home/kdev4/src/kde40svn/trunk/KDE/kdelibs- \ bindir: -/home/kdev4/src/kde40svn/trunk/KDE/kdelibs- kdelibs requires an out of source build. Please create a separate build directory \ and run 'cmake path_to_kdelibs [options]' there. -- Configuring done > Bye > Alex Cheers, Kurt ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: "Please create a separate build directory and run 'cmake path_to_kdelibs [options]' there."
On Wednesday 29 March 2006 18:44, Matt Rogers wrote: > On Wed, Mar 29, 2006 at 05:21:01PM +, Kurt Pfeifle wrote: > > Hi, > > > > today (after a week or so not trying to compile), I get this error: > > > > [EMAIL PROTECTED]:~/KDE/build/kdelibs> cmake ../../kdelibs > > kdelibs requires an out of source build. Please create a separate build \ > >directory and run 'cmake path_to_kdelibs [options]' there. > > -- Configuring done > > > > I wasn't able to follow the list for any changes, so please bear with me if > > I missed some obvious buildchange announcement. > > > > But I'm definitely in (an even virgin) "out of source" build directory. The > > source dir is also freshly checked out (into another virgin directory). > > > > What could be causing this error? A mistake, where someone has erraneously > > committed generated cmake files into SVN? Or something I'm doing wrong on > > my part? > > > > Cheers, > > Kurt > > and after reading this mail again, i was completely off. is there a > source tree in your ~/KDE/build/kdelibs folder? No. Unless it hides itself very well. > Perhaps you need to just > "rm -rf *" in your ~/KDE/build/kdelibs folder and try again. I'm not > really sure what the problem is. I had nuked srcdir as well as builddir and re-created both (that's why I called them both "virgin"). > Sorry for the previous mail with completely wrong info. Heh. It happens :-) Thanks for caring at all. Cheers, Kurt ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: Broken continuous build for KDE dash17.kitware/Linux-Debian-gcc4.1
At 11:04 AM 3/28/2006, David Faure wrote: >Any reason why we get two mails with 10s interval for each failing build, BTW? >The only difference seems to be >To: [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL >PROTECTED], [EMAIL PROTECTED] >in the first one. > >PS: is [EMAIL PROTECTED] a fake address or one that someone actually reads? There are two continuous machines running, each time there is a failure on a machine there is an email sent. The subject line should be different, dash17 or matt.rogers. [EMAIL PROTECTED] gets sent to me. -Bill ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: "Please create a separate build directory and run 'cmake path_to_kdelibs [options]' there."
On Wednesday 29 March 2006 19:21, Kurt Pfeifle wrote: > Hi, > > today (after a week or so not trying to compile), I get this error: > > [EMAIL PROTECTED]:~/KDE/build/kdelibs> cmake ../../kdelibs > kdelibs requires an out of source build. Please create a separate build \ >directory and run 'cmake path_to_kdelibs [options]' there. > -- Configuring done > > I wasn't able to follow the list for any changes, so please bear with me if > I missed some obvious buildchange announcement. > > But I'm definitely in (an even virgin) "out of source" build directory. The > source dir is also freshly checked out (into another virgin directory). > > What could be causing this error? A mistake, where someone has erraneously > committed generated cmake files into SVN? Or something I'm doing wrong on > my part? Please update kdelibs/CMakeLists.txt, I inserted some debug output, so you see what cmake considers to be the sourcedir and the builddir. Maybe you find the problem yourself, otherwise please post the output here. (starts with: "debug output for Kurt") Bye Alex -- Work: alexander.neundorf AT jenoptik.com - http://www.jenoptik-los.de Home: neundorf AT kde.org- http://www.kde.org alex AT neundorf.net - http://www.neundorf.net ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: "Please create a separate build directory and run 'cmake path_to_kdelibs [options]' there."
On 3/29/06, Kurt Pfeifle <[EMAIL PROTECTED]> wrote: > My "cmake path_to_kdelibs" uses a relative path though -- could that > be an issue? No, a relative path there should be completely fine. I wonder if there is some sort of limit on the cmake string compare functions. How long is the full path to your source and build trees? Here's something you might try. Can you rename your build directory something like kdelibs-build and rerun cmake? It should not make a difference, but if the string compare function is getting confused that should make it work. It also might make sense to have the error message print out what it thinks the source and attempted build directory are. Something like the patch I have attached. I can add that to the CMakeLists.txt file if that sounds like a good idea. Cheers, Tanner -- Tanner Lovelace clubjuggler at gmail dot com http://wtl.wayfarer.org/ (fieldless) In fess two roundels in pale, a billet fesswise and an increscent, all sable. kdelibs-print-source-build-dir.diff Description: Binary data ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: make -k not working
On Wednesday 29 March 2006 21:01, Thiago Macieira wrote: > Brad King wrote: > >When a compilation error prevents some library A from building then any > >library B that depends on (links to) library A will not attempt to > >build. Technically library B's object files could be built but library > >B could still not be linked under "make -k". > > This is exactly what I want. It really isn't a problem when you have a > compile farm, but when you don't, you can launch a make -k build at > night, go to bed and in the next morning you fix what failed to build. > Hopefully, it will be quick to fix and you'd only need to link what came > afterwards the build. So if I understood correctly, just use make -i ? cmake generates makefiles which do more dependency checking than we had with autotools AFAICT, and that's actually a good thing. Bye Alex -- Work: alexander.neundorf AT jenoptik.com - http://www.jenoptik-los.de Home: neundorf AT kde.org- http://www.kde.org alex AT neundorf.net - http://www.neundorf.net ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: Moc/uic etc without KDE cmake dependency
On Wednesday 29 March 2006 02:09, Craig Bradney wrote: > Hi, > > I'm attempting to convert Scribus to use cmake, as we want to escape > autohell too :) so.. I'm making progress but am stuck for examples on some > basics. Its been suggested I would find the most information on this list. > > The first one is how to moc a source file without using the kde3_automoc > macro (which in turn depends on a dependency macro in kde3 cmake files). I > have the cmake tarball build from the 17th IIRC (only link I had from the > KDE cmake pages anyway). > > Is there a general pure Qt (v3) solution out there? I've found a lot of Yes. Just use the QT_WRAP_CPP() and QT_WRAP_UI() commands coming with standard cmake. Their interface is a bit different from the ones used for Qt4, but you should be able to figure it out :-) Bye Alex P.S. I'll write a short howto compile kde3/4/qt4 software using cmake ASAP -- Work: alexander.neundorf AT jenoptik.com - http://www.jenoptik-los.de Home: neundorf AT kde.org- http://www.kde.org alex AT neundorf.net - http://www.neundorf.net ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: Problems with path search order
On Tuesday 28 March 2006 23:11, Albert Astals Cid wrote: > A Dimarts 28 Març 2006 23:04, David Faure va escriure: > > On Tuesday 28 March 2006 21:36, Thiago Macieira wrote: > > > Albert Astals Cid wrote: > > > >That has worked for ages (since i began developing for KDE), is your > > > >recommendation to make my (and lots of people more) life harder? > > > > > > No, easier. It happens all the time that someone gets a compilation > > > error because an incompatible version of the KDE libraries was found in > > > /usr/lib and brought in during linking or running one of our helper > > > programs. > > > > > > I had it this weekend again. My build was complaining that it couldn't > > > find a Mandriva-specific symbol inside libkio.so.4. > > > > Yep it was happening to me too, with the old buildsystem, whenever some > > $(KDE_RPATH) was missing somewhere, or worse, when the order of "foo.la > > $(LIB_BAR)" in LDADD was wrong... Too many hidden side effects there > > So Albert, if it worked for you, it's because others like me had fixed up > > Makefile.ams for such issues before you got to compile them ;) > > Well, we all know you rule ;-) > > But that's what i mean, it can be fixed, because we have had it working in > the past and asking people to remove their default KDE installation from > /usr/lib is "too much" imho. > > BTW, now that cmake devels agreed my patch is correct could we get it > commited? Sure, I'll do so ASAP. Bye Alex -- Work: alexander.neundorf AT jenoptik.com - http://www.jenoptik-los.de Home: neundorf AT kde.org- http://www.kde.org alex AT neundorf.net - http://www.neundorf.net ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: "Please create a separate build directory and run 'cmake path_to_kdelibs [options]' there."
On Wednesday 29 March 2006 18:41, Matt Rogers wrote: > On Wed, Mar 29, 2006 at 05:21:01PM +, Kurt Pfeifle wrote: > > Hi, > > > > today (after a week or so not trying to compile), I get this error: > > > > [EMAIL PROTECTED]:~/KDE/build/kdelibs> cmake ../../kdelibs > > kdelibs requires an out of source build. Please create a separate build \ > >directory and run 'cmake path_to_kdelibs [options]' there. > > -- Configuring done > > > > I wasn't able to follow the list for any changes, so please bear with me if > > I missed some obvious buildchange announcement. > > > > But I'm definitely in (an even virgin) "out of source" build directory. The > > source dir is also freshly checked out (into another virgin directory). > > > > What could be causing this error? A mistake, where someone has erraneously > > committed generated cmake files into SVN? Or something I'm doing wrong on > > my part? > > > > Cheers, > > Kurt > > kdelibs requires a srcdir != builddir configuration now. this means > you'll need to create a seperate directory to compile kdelibs in, > something like the following will work > > cd /path/to/kdelibs > mkdir build > cd build > cmake .. > make > etc. > > hope this helps No. If you look at what I wrote, that *IS* what I'm doing.:-) (And I never did any different since the last 3 years.) My "cmake path_to_kdelibs" uses a relative path though -- could that be an issue? > -- > Matt Cheers, Kurt ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: make -k not working
Brad King wrote: >When a compilation error prevents some library A from building then any >library B that depends on (links to) library A will not attempt to >build. Technically library B's object files could be built but library >B could still not be linked under "make -k". This is exactly what I want. It really isn't a problem when you have a compile farm, but when you don't, you can launch a make -k build at night, go to bed and in the next morning you fix what failed to build. Hopefully, it will be quick to fix and you'd only need to link what came afterwards the build. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org thiago.macieira (AT) trolltech.com Trolltech AS GPG: 0x6EF45358 | Sandakerveien 116, E067 918B B660 DBD1 105C | NO-0402 966C 33F5 F005 6EF4 5358 | Oslo, Norway pgpZrtbF78Hpt.pgp Description: PGP signature ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: make -k not working
Matt Rogers wrote: > On Wed, Mar 29, 2006 at 07:38:07PM +0200, Thiago Macieira wrote: > >>I've also noticed that make -k isn't working in the cmake builds. Whenever >>it finds an error, it halts the compilation completely, instead of >>ignoring (like I told it to). What's even more interesting, going to >>another directory, completely unrelated to the error, also doesn't work. >> >>Also, it's quite possible that the dependencies are blocking a full >>parallel build, since the inability to link one library is stopping the >>build to proceed and compile the next library's source files. >> >>[snip build errors] > > > use -i instead of -k. it's what's being used for the dashboards and it > works. However, I don't know why -k is not working Using "make -k" says "build everything whose dependencies built successfully", and "make -i" says "build everything no matter what". When a compilation error prevents some library A from building then any library B that depends on (links to) library A will not attempt to build. Technically library B's object files could be built but library B could still not be linked under "make -k". The reason things seem to stop early for CMake-generated projects is that in order to handle inter-target dependencies and generated sources properly each target is built by its own make process. A top-level make process knows only of the inter-target dependencies and runs a sub-make for each one. This is similar to how Visual Studio works. If a target fails then any target that depends on it cannot be built according to "make -k". -Brad ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: New cmake tarball needed
A Dimecres 29 Març 2006 09:32, Laurent Montel va escriure:
> On Tuesday 28 March 2006 19:37, Albert Astals Cid wrote:
> > A Dimarts 28 Març 2006 10:39, Laurent Montel va escriure:
> > > On Tuesday 28 March 2006 10:23, David Faure wrote:
> > > > On Monday 27 March 2006 21:26, Alexander Neundorf wrote:
> > > > > We should only use features of the latest released cmake I think
> > > > > (which is 2.3.4 right now), in order to avoid too frequent cmake
> > > > > updates.
> > > >
> > > > Yes, this is exactly why I had to disable srcdir==builddir, since the
> > > > latest released cmake breaks in that case.
> > >
> > > It's necessary to release a stable version.
> > > I found that cmake from cvs doesn't search lib in good directory.
> > >find_library(KDE4_KDECORE_LIBRARY NAMES kdecore PATHS
> > > ${KDE4_LIB_INSTALL_DIR} )
> >
> > Maybe because you need my patch?
> >
> > And no it's not a bug, cmake man page clearly states the supplied paths
> > are looked the last ones by default.
>
> So for me it's not logical.
> We specify PATH where to search and it searchs into at the end.
> For me when we specify a path we want that this path has a high priority,
> and not low priority.
It is not logical for me neither, but i'm not a cmake developer ;-)
Albert
> ___
> Kde-buildsystem mailing list
> Kde-buildsystem@kde.org
> https://mail.kde.org/mailman/listinfo/kde-buildsystem
__
LLama Gratis a cualquier PC del Mundo.
Llamadas a fijos y móviles desde 1 céntimo por minuto.
http://es.voice.yahoo.com
___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: make -k not working
On Wed, Mar 29, 2006 at 07:38:07PM +0200, Thiago Macieira wrote: > I've also noticed that make -k isn't working in the cmake builds. Whenever > it finds an error, it halts the compilation completely, instead of > ignoring (like I told it to). What's even more interesting, going to > another directory, completely unrelated to the error, also doesn't work. > > Also, it's quite possible that the dependencies are blocking a full > parallel build, since the inability to link one library is stopping the > build to proceed and compile the next library's source files. > > [snip build errors] use -i instead of -k. it's what's being used for the dashboards and it works. However, I don't know why -k is not working -- Matt ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: "Please create a separate build directory and run 'cmake path_to_kdelibs [options]' there."
On Wed, Mar 29, 2006 at 05:21:01PM +, Kurt Pfeifle wrote: > Hi, > > today (after a week or so not trying to compile), I get this error: > > [EMAIL PROTECTED]:~/KDE/build/kdelibs> cmake ../../kdelibs > kdelibs requires an out of source build. Please create a separate build \ >directory and run 'cmake path_to_kdelibs [options]' there. > -- Configuring done > > I wasn't able to follow the list for any changes, so please bear with me if > I missed some obvious buildchange announcement. > > But I'm definitely in (an even virgin) "out of source" build directory. The > source dir is also freshly checked out (into another virgin directory). > > What could be causing this error? A mistake, where someone has erraneously > committed generated cmake files into SVN? Or something I'm doing wrong on > my part? > > Cheers, > Kurt and after reading this mail again, i was completely off. is there a source tree in your ~/KDE/build/kdelibs folder? Perhaps you need to just "rm -rf *" in your ~/KDE/build/kdelibs folder and try again. I'm not really sure what the problem is. Sorry for the previous mail with completely wrong info. -- Matt ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: "Please create a separate build directory and run 'cmake path_to_kdelibs [options]' there."
On Wed, Mar 29, 2006 at 05:21:01PM +, Kurt Pfeifle wrote: > Hi, > > today (after a week or so not trying to compile), I get this error: > > [EMAIL PROTECTED]:~/KDE/build/kdelibs> cmake ../../kdelibs > kdelibs requires an out of source build. Please create a separate build \ >directory and run 'cmake path_to_kdelibs [options]' there. > -- Configuring done > > I wasn't able to follow the list for any changes, so please bear with me if > I missed some obvious buildchange announcement. > > But I'm definitely in (an even virgin) "out of source" build directory. The > source dir is also freshly checked out (into another virgin directory). > > What could be causing this error? A mistake, where someone has erraneously > committed generated cmake files into SVN? Or something I'm doing wrong on > my part? > > Cheers, > Kurt kdelibs requires a srcdir != builddir configuration now. this means you'll need to create a seperate directory to compile kdelibs in, something like the following will work cd /path/to/kdelibs mkdir build cd build cmake .. make etc. hope this helps -- Matt ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
make -k not working
I've also noticed that make -k isn't working in the cmake builds. Whenever it finds an error, it halts the compilation completely, instead of ignoring (like I told it to). What's even more interesting, going to another directory, completely unrelated to the error, also doesn't work. Also, it's quite possible that the dependencies are blocking a full parallel build, since the inability to link one library is stopping the build to proceed and compile the next library's source files. Here's what I'm seeing: $ make Building CXX object kdeui/CMakeFiles/kdeui.dir/kprogressdialog.o [ error message ] make[2]: *** [kdeui/CMakeFiles/kdeui.dir/kprogressdialog.o] Error 1 make[1]: *** [kdeui/CMakeFiles/kdeui.dir/all] Error 2 make: *** [all] Error 2 $ make -k Building CXX object kdeui/CMakeFiles/kdeui.dir/kprogressdialog.o [ error message ] make[2]: *** [kdeui/CMakeFiles/kdeui.dir/kprogressdialog.o] Error 1 make[2]: Target `kdeui/CMakeFiles/kdeui.dir/build' not remade because of errors. make[1]: *** [kdeui/CMakeFiles/kdeui.dir/all] Error 2 make[1]: Target `all' not remade because of errors. make: *** [all] Error 2 make: Target `default_target' not remade because of errors. $ make -C khtml make: Entering directory `/home/tjmaciei/obj/kde4/KDE/kdelibs/khtml' make[1]: Entering directory `/home/tjmaciei/obj/kde4/KDE/kdelibs' make[2]: Entering directory `/home/tjmaciei/obj/kde4/KDE/kdelibs' Building CXX object kdeui/CMakeFiles/kdeui.dir/kprogressdialog.o [ error message ] make[2]: *** [kdeui/CMakeFiles/kdeui.dir/kprogressdialog.o] Error 1 make[2]: Leaving directory `/home/tjmaciei/obj/kde4/KDE/kdelibs' make[1]: *** [kdeui/CMakeFiles/kdeui.dir/all] Error 2 make[1]: Leaving directory `/home/tjmaciei/obj/kde4/KDE/kdelibs' make: *** [all] Error 2 make: Leaving directory `/home/tjmaciei/obj/kde4/KDE/kdelibs/khtml' $ make -k -C khtml make: Entering directory `/home/tjmaciei/obj/kde4/KDE/kdelibs/khtml' make[1]: Entering directory `/home/tjmaciei/obj/kde4/KDE/kdelibs' make[2]: Entering directory `/home/tjmaciei/obj/kde4/KDE/kdelibs' Building CXX object kdeui/CMakeFiles/kdeui.dir/kprogressdialog.o [ error message ] make[2]: *** [kdeui/CMakeFiles/kdeui.dir/kprogressdialog.o] Error 1 make[2]: Target `kdeui/CMakeFiles/kdeui.dir/build' not remade because of errors. make[2]: Leaving directory `/home/tjmaciei/obj/kde4/KDE/kdelibs' make[1]: *** [kdeui/CMakeFiles/kdeui.dir/all] Error 2 make[1]: Target `khtml/all' not remade because of errors. make[1]: Leaving directory `/home/tjmaciei/obj/kde4/KDE/kdelibs' make: *** [all] Error 2 make: Target `default_target' not remade because of errors. make: Leaving directory `/home/tjmaciei/obj/kde4/KDE/kdelibs/khtml' PS: I've fixed the bug in kprogressdialog.cpp already. Use svnrevertlast to reproduce. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org thiago.macieira (AT) trolltech.com Trolltech AS GPG: 0x6EF45358 | Sandakerveien 116, E067 918B B660 DBD1 105C | NO-0402 966C 33F5 F005 6EF4 5358 | Oslo, Norway pgp21XKaKtA5f.pgp Description: PGP signature ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: please verify: parallel builds are working now
Thiago Macieira wrote: > Brad King wrote: > >>When a build tree is first created by CMake it becomes locked to the >>compiler specified the first time. If the compiler is not specified >>with a full path then the PATH is searched to find it, and then that >>full path is used. It is not safe to build some of a tree with one >>compiler and then the rest with another in C++ anyway. Even if the >>compilers share an ABI the try-compile results may be different. > > > The point is I *want* to switch compilers. > > I want to switch between gcc, colorgcc and teambuilder/icecream/etc. > > And I do that by setting PATH. Currently, the only want to switch > compilers is to rm -rf * and reconfigure. > > This is how I work: > $ teambuilder off > $ cmake /path/to/src/kdelibs > $ teambuilder on > $ make -kj25 > > $ make > > > I don't want to run all the configure tests with Teambuilder because they > are all mostly small and the overhead of sending to another machine, > compiling and sending back isn't worth it. But I do want to make the > gross (-k) compilation with Teambuilder to get most everything out of the > way. > > Currently, I have no choice but to run all the configure tests with the > compile farm. Just create a shell script that runs the compiler via the path and use that as the CMake compiler: CC=mycc.sh CXX=mycxx.sh cmake ... In mycc.sh write: -- #!/bin/sh exec gcc "$@" -- In mycxx.sh write: -- #!/bin/sh exec g++ "$@" -- -Brad ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: please verify: parallel builds are working now
Brad King wrote: >When a build tree is first created by CMake it becomes locked to the >compiler specified the first time. If the compiler is not specified >with a full path then the PATH is searched to find it, and then that >full path is used. It is not safe to build some of a tree with one >compiler and then the rest with another in C++ anyway. Even if the >compilers share an ABI the try-compile results may be different. The point is I *want* to switch compilers. I want to switch between gcc, colorgcc and teambuilder/icecream/etc. And I do that by setting PATH. Currently, the only want to switch compilers is to rm -rf * and reconfigure. This is how I work: $ teambuilder off $ cmake /path/to/src/kdelibs $ teambuilder on $ make -kj25 $ make I don't want to run all the configure tests with Teambuilder because they are all mostly small and the overhead of sending to another machine, compiling and sending back isn't worth it. But I do want to make the gross (-k) compilation with Teambuilder to get most everything out of the way. Currently, I have no choice but to run all the configure tests with the compile farm. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org thiago.macieira (AT) trolltech.com Trolltech AS GPG: 0x6EF45358 | Sandakerveien 116, E067 918B B660 DBD1 105C | NO-0402 966C 33F5 F005 6EF4 5358 | Oslo, Norway pgpIWHLkyfdIS.pgp Description: PGP signature ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: please verify: parallel builds are working now
At 10:49 AM 3/29/2006, you wrote: >When a build tree is first created by CMake it becomes locked to the >compiler specified the first time. If the compiler is not specified >with a full path then the PATH is searched to find it, and then that >full path is used. It is not safe to build some of a tree with one >compiler and then the rest with another in C++ anyway. Even if the >compilers share an ABI the try-compile results may be different. To add to the issues with switching the compilers like that, all the try compile results were done with one compiler, and then you are trying to use a different compiler. Obviously that could cause trouble. -Bill ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
"Please create a separate build directory and run 'cmake path_to_kdelibs [options]' there."
Hi, today (after a week or so not trying to compile), I get this error: [EMAIL PROTECTED]:~/KDE/build/kdelibs> cmake ../../kdelibs kdelibs requires an out of source build. Please create a separate build \ directory and run 'cmake path_to_kdelibs [options]' there. -- Configuring done I wasn't able to follow the list for any changes, so please bear with me if I missed some obvious buildchange announcement. But I'm definitely in (an even virgin) "out of source" build directory. The source dir is also freshly checked out (into another virgin directory). What could be causing this error? A mistake, where someone has erraneously committed generated cmake files into SVN? Or something I'm doing wrong on my part? Cheers, Kurt ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
RE: Build errors
> -Original Message- > From: William A. Hoffman [mailto:[EMAIL PROTECTED] > Sent: quarta-feira, 29 de Março de 2006 15:42 > To: kde-buildsystem@kde.org > Subject: Re: Build errors > > What is the current status of the windows build? > Is it time to set up a dashboard? I have not done so > yet, because it did not compile without errors. Should > kdelibs compile without errors on windows now? I can't test lately as I can't build Qt (from Trolltech) from source: $ make cd src && make -f Makefile make[1]: Entering directory `/d/kde/qt-win-opensource-src-4.1.3-snapshot-20060322/src' make[1]: *** No rule to make target `..\.qmake.cache', needed by `Makefile'. Stop. make[1]: Leaving directory `/d/kde/qt-win-opensource-src-4.1.3-snapshot-20060322/src' make: *** [sub-src-make_default-ordered] Error 2 Paulo ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: Build errors
At 10:15 AM 3/29/2006, Christian Ehrlicher wrote: >William A. Hoffman schrieb: > >It compiled some time ago - currently I don't know because of the >changes in khtml & kjs. Which is why a dashboard build is needed. :) -Bill ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: Build errors
At 10:15 AM 3/29/2006, Christian Ehrlicher wrote: >William A. Hoffman schrieb: >> What is the current status of the windows build? >> Is it time to set up a dashboard? I have not done so >> yet, because it did not compile without errors. Should >> kdelibs compile without errors on windows now? >It compiled some time ago - currently I don't know because of the >changes in khtml & kjs. >But the test programs won't run with msvc because of release <-> debug >problems. MinGW should work fine here. What if the whole thing is built release? That should work right? -Bill ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: please verify: parallel builds are working now
Thiago Macieira wrote: > Alexander Neundorf wrote: > >>I just successfully compiled kdelibs/ from trunk with "make -j4" on my >>single processor machine. >>Could you please verify that it also works for your setups ? >>If there are problems, let me know. > > I tried a make -j25 on the compile farm here at Trolltech and suddenly > realised my machine was grinding to a halt. It appears that cmake > runs "/usr/bin/gcc" no matter which gcc is found first in PATH. > > How can I tell cmake to generate Makefiles that run "gcc" and > not "/usr/bin/gcc"? I don't want to erase the whole cache every time I > want to switch compilers. When a build tree is first created by CMake it becomes locked to the compiler specified the first time. If the compiler is not specified with a full path then the PATH is searched to find it, and then that full path is used. It is not safe to build some of a tree with one compiler and then the rest with another in C++ anyway. Even if the compilers share an ABI the try-compile results may be different. If you want to switch compilers just create another build tree. I frequently use a layout like this: Foo # Source tree Foo-gcc-3.3 # Build tree with GCC 3.3 Foo-gcc-4.0 # Build tree with GCC 4.0 Foo-icc-8.1 # Build tree with Intel C++ 8.1 -Brad ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: Build errors
William A. Hoffman schrieb: > What is the current status of the windows build? > Is it time to set up a dashboard? I have not done so > yet, because it did not compile without errors. Should > kdelibs compile without errors on windows now? It compiled some time ago - currently I don't know because of the changes in khtml & kjs. But the test programs won't run with msvc because of release <-> debug problems. MinGW should work fine here. Christian signature.asc Description: OpenPGP digital signature ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: Build errors
What is the current status of the windows build? Is it time to set up a dashboard? I have not done so yet, because it did not compile without errors. Should kdelibs compile without errors on windows now? -Bill ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: Build errors
On Wednesday 29 March 2006 16:02, Maarten Th. Mulders wrote: > Hi all, > > again, more build errors. How come some people report problemless builds? ;) > Anyway, while building kdeui: > > Building CXX object kdecore/CMakeFiles/kdecore.dir/kacceleratormanager.obj > kacceleratormanager.cpp > D:\source\kde-svn\kdelibs\kdeui\kactionclasses.h(224) : error C2504: > 'QActionWidgetFactory' : base class undefined You need to apply the patches from trunk/qt-copy/patches to your version of Qt, for now. -- 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: Build errors
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi all, again, more build errors. How come some people report problemless builds? ;) Anyway, while building kdeui: Building CXX object kdecore/CMakeFiles/kdecore.dir/kacceleratormanager.obj kacceleratormanager.cpp D:\source\kde-svn\kdelibs\kdeui\kactionclasses.h(224) : error C2504: 'QActionWidgetFactory' : base class undefined D:\source\kde-svn\kdelibs\kdeui\kactionclasses.h(560) : error C2061: syntax error : identifier 'QToolBar' D:\source\kde-svn\kdelibs\kdeui\kactionclasses.h(879) : error C2061: syntax error : identifier 'QToolBar' D:\source\kde-svn\kdelibs\kdeui\kactionclasses.h(946) : error C2504: 'QActionWidgetFactory' : base class undefined D:\source\kde-svn\kdelibs\kdeui\kactionclasses.h(1015) : error C2061: syntax error : identifier 'QToolBar' D:\source\kde-svn\kdelibs\kdeui\kactionclasses.h(1031) : error C2504: 'QActionWidgetFactory' : base class undefined D:\source\kde-svn\kdelibs\kdeui\kactionclasses.h(1128) : error C2061: syntax error : identifier 'QToolBar' D:\source\kde-svn\kdelibs\kdeui\kactionclasses.h(1244) : error C2504: 'QActionWidgetFactory' : base class undefined D:\source\kde-svn\kdelibs\kdeui\kactionclasses.h(1263) : error C2061: syntax error : identifier 'QToolBar' D:\source\kde-svn\kdelibs\kdecore\kacceleratormanager.cpp(408) : warning C4018:'<' : signed/unsigned mismatch D:\source\kde-svn\kdelibs\kdecore\kacceleratormanager.cpp(783) : warning C4018:'<' : signed/unsigned mismatch D:\source\kde-svn\kdelibs\kdecore\kacceleratormanager.cpp(810) : warning C4018:'<' : signed/unsigned mismatch Ideas, anyone? Thanks in advance, Maarten Th. Mulders - -- The digital signature in this email can be checked with * Thunderbird: the Enigmail-extension (http://enigmail.mozdev.org/) * Outlook (Express): the GnuPG-Plugin (http://www3.gdata.de/gpg/index.html). -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.2 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEKpNvrlDGjB4EDkARAof+AKCX9kXc3FdkGGknzL4maNQR/he31ACdFk4F FMBJ4mnMdR2QyHYznjSKzbg= =Qxm+ -END PGP SIGNATURE- ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: New cmake tarball needed
At 02:32 AM 3/29/2006, Laurent Montel wrote: >So for me it's not logical. >We specify PATH where to search and it searchs into at the end. >For me when we specify a path we want that this path has a high priority, and >not low priority. But you are not always the end user. So, if a user puts program foo in their PATH, and there is a FIND_PROGRAM(foo /my/path/), as a user of cmake I would expect the foo in my PATH to be found, and not the one that was hard coded into the cmakelist file. Same thing goes for LIB and INCLUDE variables.CMake should work like the shell, and use the environment it is given, not the additional search paths specified by the cmakelist writer. But, if you disagree with this, there is a way to change the order. At the end of the day, most FIND* stuff should not have to specify many paths anyway, because all the normal locations should be in cmake. -Bill ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: Different Linkage
> Hi all, > > quite a big chance I am doing something wrong again, but here is my > question: > when building KDElibs with Visual C++ 2005 Express all goes well until > building kdecore, especially kapplication.cpp. > There, the following error occurs: > > D:\source\kde-svn\kdelibs\kdecore\klocalizedstring.h(362) : error C2375: > 'ki18n' : redefinition; different linkage > D:\source\kde-svn\kdelibs\kdecore\klocalizedstring.h(205) : see > declaration of 'ki18n' You have to add 'KDECORE_EXPORT' in line 205-208 too -> http://websvn.kde.org/trunk/KDE/kdelibs/kdecore/klocalizedstring.h?rev=523168&r1=523127&r2=523168 Christian -- Echte DSL-Flatrate dauerhaft für 0,- Euro*! "Feel free" mit GMX DSL! http://www.gmx.net/de/go/dsl ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Different Linkage
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi all, quite a big chance I am doing something wrong again, but here is my question: when building KDElibs with Visual C++ 2005 Express all goes well until building kdecore, especially kapplication.cpp. There, the following error occurs: D:\source\kde-svn\kdelibs\kdecore\klocalizedstring.h(362) : error C2375: 'ki18n' : redefinition; different linkage D:\source\kde-svn\kdelibs\kdecore\klocalizedstring.h(205) : see declaration of 'ki18n' D:\source\kde-svn\kdelibs\kdecore\klocalizedstring.h(376) : error C2375: 'ki18nc' : redefinition; different linkage D:\source\kde-svn\kdelibs\kdecore\klocalizedstring.h(206) : see declaration of 'ki18nc' D:\source\kde-svn\kdelibs\kdecore\klocalizedstring.h(388) : error C2375: 'ki18np' : redefinition; different linkage D:\source\kde-svn\kdelibs\kdecore\klocalizedstring.h(207) : see declaration of 'ki18np' D:\source\kde-svn\kdelibs\kdecore\klocalizedstring.h(404) : error C2375: 'ki18ncp' : redefinition; different linkage D:\source\kde-svn\kdelibs\kdecore\klocalizedstring.h(208) : see declaration of 'ki18ncp' D:\source\kde-svn\kdelibs\kdecore\klocalizedstring.h(418) : error C2228: left of '.toString' must have class/struct/union D:\source\kde-svn\kdelibs\kdecore\klocalizedstring.h(418) : error C3861: 'ki18n': identifier not found D:\source\kde-svn\kdelibs\kdecore\klocalizedstring.h(455) : error C2228: left of '.toString' must have class/struct/union D:\source\kde-svn\kdelibs\kdecore\klocalizedstring.h(455) : error C3861: 'ki18nc': identifier not found D:\source\kde-svn\kdelibs\kdecore\klocalizedstring.h(487) : error C2228: left of '.subs' must have class/struct/union D:\source\kde-svn\kdelibs\kdecore\klocalizedstring.h(487) : error C2228: left of '.toString' must have class/struct/union D:\source\kde-svn\kdelibs\kdecore\klocalizedstring.h(487) : error C3861: 'ki18np': identifier not found D:\source\kde-svn\kdelibs\kdecore\klocalizedstring.h(519) : error C2228: left of '.subs' must have class/struct/union D:\source\kde-svn\kdelibs\kdecore\klocalizedstring.h(519) : error C2228: left of '.toString' must have class/struct/union D:\source\kde-svn\kdelibs\kdecore\klocalizedstring.h(519) : error C3861: 'ki18ncp': identifier not found Ideas, anyone? Thanks in advance, Maarten Th. Mulders - -- De digitale handtekening voor deze mail is te controleren met * Thunderbird: de Enigmail-extensie (http://enigmail.mozdev.org/) * Outlook (Express): de GnuPG-Plugin (http://www3.gdata.de/gpg/index.html). -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.2 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEKn0qrlDGjB4EDkARAkf5AJ0UMbKntPTvQLvkglc6v/QoO+fjNACdEcGp dG6yfEsZzFKWOOC9BsbtQtU= =d/+p -END PGP SIGNATURE- ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: please verify: parallel builds are working now
Alexander Neundorf wrote: >Hi, > >I just successfully compiled kdelibs/ from trunk with "make -j4" on my > single processor machine. >Could you please verify that it also works for your setups ? >If there are problems, let me know. I tried a make -j25 on the compile farm here at Trolltech and suddenly realised my machine was grinding to a halt. It appears that cmake runs "/usr/bin/gcc" no matter which gcc is found first in PATH. How can I tell cmake to generate Makefiles that run "gcc" and not "/usr/bin/gcc"? I don't want to erase the whole cache every time I want to switch compilers. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org thiago.macieira (AT) trolltech.com Trolltech AS GPG: 0x6EF45358 | Sandakerveien 116, E067 918B B660 DBD1 105C | NO-0402 966C 33F5 F005 6EF4 5358 | Oslo, Norway pgptDLsYhZJ2s.pgp Description: PGP signature ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: RPATH again - different types of executables
Brad King wrote: >You're probably right. I've never encountered the problem because I use >CMake for everything. It automatically pulls in library dependencies >and links the executable explicitly to all libraries (at least if the >project providing the libs uses export_library_dependencies properly). Which is actually the source of the problem I had this weekend (which I mentioned in the reply to Albert). My KDE 3.5 build uses the linker flag --as-needed automatically. This means libraries and executables don't link to libraries they don't import any symbols from. In turn, the search path is screwed up before installation, since (real example) knewstuff/khotnewstuff links to knewstuff/libknewstuff.la, which pulls in libkio, which pulls in libkdeui. During linking, I get lots of linker warnings like "libkio.so.4 needed by libknewstuff.so.1 not found; maybe you need -rpath or -rpath-link". I would have solved this problem a long time ago if I could actually understand libtool code... >Inside the kdelibs build tree CMake will link the executables to >everything they need so the library search paths will not be needed. >Perhaps they could be built with the install tree rpath only. I'm not >sure what the precedence is though so that might conflict with the >executable's rpath. Someone will have to investigate. The libraries should have rpath set to the install dir only. That should be more than enough. If you run an uninstalled program, the LD_LIBRARY_PATH setting should take over and let it find everything. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org thiago.macieira (AT) trolltech.com Trolltech AS GPG: 0x6EF45358 | Sandakerveien 116, E067 918B B660 DBD1 105C | NO-0402 966C 33F5 F005 6EF4 5358 | Oslo, Norway pgpqiHy7jXiaj.pgp Description: PGP signature ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: CMake and OCaml
Hi I will give you the whole set of commands we are currently performing to "compile" the ocaml-file. OCaml is very c-like... ocamldep -I +facile *.mli *.ml > .depend ocamlc -I +facile -c chemset.mli ocamlopt -I +facile -c chemset.ml ocamlc -I +facile -c parser.mli ocamlopt -I +facile -c parser.ml ocamlopt -I +facile -c lexer.ml ocamlc -I +facile -c datastruct.mli ocamlopt -I +facile -c datastruct.ml ocamlc -I +facile -c chem.mli ocamlopt -I +facile -c chem.ml ocamlc -I +facile -c calc.mli ocamlopt -I +facile -c calc.ml ocamlopt -I +facile -c modwrap.c ocamlopt -output-obj -o solver.o `ocamlc -where`/facile/facile.cmxa chemset.cmx parser.cmx lexer.cmx datastruct.cmx chem.cmx calc.cmx cp -f solver.o modwrap.o ../ ocamlopt - The Objective Caml native-code compiler ocamlopt [ -acivS ] [ -cclib libname ] [ -ccopt option ] [ -compact ] [ -unsafe ] [ -o exec-file ] [ -I lib-dir ] filename ... ocamlc - The Objective Caml bytecode compiler ocamlc [ -aciv ] [ -cclib libname ] [ -ccopt option ] [ -custom ] [ -unsafe ] [ -o exec-file ] [ -I lib-dir ] filename ... ocamldep - Dependency generator for Objective Caml ocamldep [ -I lib-dir ] filename ... I hope this is what you want If not, this is a nice walk-through http://www.ocaml-tutorial.org/compiling_ocaml_projects Carsten pgp6F7zN2oofN.pgp Description: PGP signature ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
