Re: Initial support for kde_projects.xml in kdesrc-build
On 04.02.11 00:33:58, David Faure wrote: On Wednesday 02 February 2011, Alexander Neundorf wrote: On Wednesday 02 February 2011, Michael Pyne wrote: ... e.g. worrying about environment variables like PKG_CONFIG_PATH is no idle claim (kdesrc-build sets that as well), along with PATH in order to pick up the right Qt version. Please try to use only CMAKE_PREFIX_PATH instead of setting PATH. I recommend this to everybody. How does this help finding *Qt*? We find Qt via `qmake`, so $PATH matters. We find Qt via find_program() which _first_ looks into all paths listed in CMAKE_PREFIX_PATH/bin and then later into PATH. Andreas -- You will be the last person to buy a Chrysler.
Re: Initial support for kde_projects.xml in kdesrc-build
On Tuesday 01 February 2011, Michael Jansen wrote: If you find the place let me know. No ... only if i am unable to fix it myself :)) . Do you need that for running ? For building it's not necessary. Use CMAKE_PREFIX_PATH. I always thought that PATH controls which qt version is selected if you have more than one (First qmake found). It was that way some time ago. And QTDIR IS USED in FindQt4.cmake. I don't reevaluate my finding every day so perhaps something changed. Ok. So when an executable is searched, it is searched in a set of default directories (as e.g. /usr/bin/) and in PATH. So setting PATH so that it points to the qmake you want works. CMAKE_PREFIX_PATH is more generic (and didn't exist in cmake 2.4.something). So you can set this too to make cmake find the Qt you want (not pointing to QTDIR/bin, but just to QTDIR). QTDIR is a variable specific to FindQt4.cmake, so it works too. So all three work, the most generic/powerful one is CMAKE_PREFIX_PATH. Then the 100 points question is: If all of them point to a directory with a qt installed (three different versions). Which one wins? a) CMAKE_PREFIX_PATH b) PATH c) QTDIR I remember more than one newbie losing his grip over not beeing able to convince cmake to pickup the right one. Can you answer it without looking at the cmake file? I can't. CMAKE_PREFIX_PATH has more or less highest priority. Of course it can be ignore when using NO_DEFAULT_PATH. Alex
Re: Initial support for kde_projects.xml in kdesrc-build
On Wednesday 02 February 2011, Michael Pyne wrote: ... e.g. worrying about environment variables like PKG_CONFIG_PATH is no idle claim (kdesrc-build sets that as well), along with PATH in order to pick up the right Qt version. Please try to use only CMAKE_PREFIX_PATH instead of setting PATH. I recommend this to everybody. I'd also suggest not to set PKG_CONFIG_PATH, at least not to directories where KDE stuff is installed, this has to be found also without pkgconfig. Alex
Re: Initial support for kde_projects.xml in kdesrc-build
On Monday 31 January 2011, Aaron J. Seigo wrote: On Sunday, January 30, 2011, Michael Pyne wrote: Like I said, xml-support branch on kdesrc-build git. If you want to give _very_ cool. will the good news today never end? ;) serious question: once this is stabilized, can we make this the default recommended way of building KDE from git on techbase? pros that i can think of: * it would mean that we could cannibalize the docs for kdesrc-build for those pages on techbase * it would be a lot simpler to document than the current 7 headed hydra monster pages we have now :) The big thing is getting all the required dependencies built and installed, or do you see other things which are complicated in building KDE modules ? Alex
Re: Initial support for kde_projects.xml in kdesrc-build
On Tuesday 01 February 2011 19:53:40 Alexander Neundorf wrote: On Monday 31 January 2011, Aaron J. Seigo wrote: On Sunday, January 30, 2011, Michael Pyne wrote: Like I said, xml-support branch on kdesrc-build git. If you want to give _very_ cool. will the good news today never end? ;) serious question: once this is stabilized, can we make this the default recommended way of building KDE from git on techbase? pros that i can think of: * it would mean that we could cannibalize the docs for kdesrc-build for those pages on techbase * it would be a lot simpler to document than the current 7 headed hydra monster pages we have now :) The big thing is getting all the required dependencies built and installed, or do you see other things which are complicated in building KDE modules ? yes i do. 1. It is a lot of work. if you work on base and want to run trunk there is a myriad of modules to build to get a useful setup. 2. environment variables (which and how to setup). Separate build environment from distro stuff that could interfere. 3. build order 4. which branches, version from which repo (only relevant for some modules) Alex
Re: Initial support for kde_projects.xml in kdesrc-build
On Tuesday 01 February 2011, Michael Jansen wrote: On Tuesday 01 February 2011 19:53:40 Alexander Neundorf wrote: On Monday 31 January 2011, Aaron J. Seigo wrote: On Sunday, January 30, 2011, Michael Pyne wrote: Like I said, xml-support branch on kdesrc-build git. If you want to give _very_ cool. will the good news today never end? ;) serious question: once this is stabilized, can we make this the default recommended way of building KDE from git on techbase? pros that i can think of: * it would mean that we could cannibalize the docs for kdesrc-build for those pages on techbase * it would be a lot simpler to document than the current 7 headed hydra monster pages we have now :) The big thing is getting all the required dependencies built and installed, or do you see other things which are complicated in building KDE modules ? yes i do. 1. It is a lot of work. if you work on base and want to run trunk there is a myriad of modules to build to get a useful setup. kdelibs, kdepimlibs, then kdebase. 2. environment variables (which and how to setup). Separate build environment from distro stuff that could interfere. CMAKE_PREFIX_PATH for finding stuff, and install your own stuff e.g. to /opt/mystuff/ Seriously, if that is not enough, what else do you have to do ? Except your lib64-rpath problem. I remember we discussed about that one. What was the outcome ? Problem in cmake itself ? 3. build order Isn't that the same as 1. ? 4. which branches, version from which repo (only relevant for some modules) You mean now with git or also with old svn ? Alex
Re: Initial support for kde_projects.xml in kdesrc-build
On Tuesday 01 February 2011 20:35:27 Alexander Neundorf wrote: On Tuesday 01 February 2011, Michael Jansen wrote: On Tuesday 01 February 2011 19:53:40 Alexander Neundorf wrote: On Monday 31 January 2011, Aaron J. Seigo wrote: On Sunday, January 30, 2011, Michael Pyne wrote: Like I said, xml-support branch on kdesrc-build git. If you want to give _very_ cool. will the good news today never end? ;) serious question: once this is stabilized, can we make this the default recommended way of building KDE from git on techbase? pros that i can think of: * it would mean that we could cannibalize the docs for kdesrc-build for those pages on techbase * it would be a lot simpler to document than the current 7 headed hydra monster pages we have now :) The big thing is getting all the required dependencies built and installed, or do you see other things which are complicated in building KDE modules ? yes i do. 1. It is a lot of work. if you work on base and want to run trunk there is a myriad of modules to build to get a useful setup. kdelibs, kdepimlibs, then kdebase. So want Aaaron and me to miss out on kwebkit and scripting, and policykit and rekonq and ... konsole? How do you suppose to use your system without konsole. kdesupport? anyone ... perhaps qt from trunk or qtsoftware to get problems as early as possible? 2. environment variables (which and how to setup). Separate build environment from distro stuff that could interfere. CMAKE_PREFIX_PATH for finding stuff, and install your own stuff e.g. to /opt/mystuff/ Do you only compile stuff? Or do you run it too? Does strigi work for you? STRIGI_PLUGIN_PATH ... but i haven't tested for a while if it needed nowadays. Strigi would not work without it. PKG_CONFIG_PATH, QTDIR (self compiled qt), PATH so your self compiled stuff is picked up, LD_LIBRARY_PATH if you want to run stuff, XDG_DATA_DIRS, KDEDIRS. 3. build order Isn't that the same as 1. ? No. kwebkitpart has to be build after kdelibs and before kdebase. Did you know that? Do you expect Joe NewKdeUser to know? The kdesupport order is much harder to get right. The strigi order? Quick. Order these smokegen, smokeqt, smokekde, qtruby, korundum. 4. which branches, version from which repo (only relevant for some modules) You mean now with git or also with old svn ? Have you ever tried to compile ktorrent? I mean with old svn too. But i expect that to get a tad more difficult with git unless we get a real common branching names strategy. Mike
Re: Initial support for kde_projects.xml in kdesrc-build
On Tuesday 01 February 2011, Michael Jansen wrote: On Tuesday 01 February 2011 20:35:27 Alexander Neundorf wrote: On Tuesday 01 February 2011, Michael Jansen wrote: On Tuesday 01 February 2011 19:53:40 Alexander Neundorf wrote: On Monday 31 January 2011, Aaron J. Seigo wrote: On Sunday, January 30, 2011, Michael Pyne wrote: Like I said, xml-support branch on kdesrc-build git. If you want to give _very_ cool. will the good news today never end? ;) serious question: once this is stabilized, can we make this the default recommended way of building KDE from git on techbase? pros that i can think of: * it would mean that we could cannibalize the docs for kdesrc-build for those pages on techbase * it would be a lot simpler to document than the current 7 headed hydra monster pages we have now :) The big thing is getting all the required dependencies built and installed, or do you see other things which are complicated in building KDE modules ? yes i do. 1. It is a lot of work. if you work on base and want to run trunk there is a myriad of modules to build to get a useful setup. kdelibs, kdepimlibs, then kdebase. So want Aaaron and me to miss out on kwebkit and scripting, and policykit and rekonq and ... konsole? How do you suppose to use your system without konsole. Yes, with git this has become more stuff. kdesupport? anyone ... perhaps qt from trunk or qtsoftware to get problems as early as possible? I was asking specifically about KDE stuff, i.e. everything starting with kdelibs, not stuff kdelibs depends on (which I also mentioned in my previous mail that this is not too easy to get set up, as you can see above). 2. environment variables (which and how to setup). Separate build environment from distro stuff that could interfere. CMAKE_PREFIX_PATH for finding stuff, and install your own stuff e.g. to /opt/mystuff/ Do you only compile stuff? Or do you run it too? I don't get that far to actually run the stuff I've compiled... A lot of the work I do _for_ KDE is actually work _on_ CMake nowadays. Does strigi work for you? STRIGI_PLUGIN_PATH ... but i haven't tested for a while if it needed nowadays. Strigi would not work without it. PKG_CONFIG_PATH, I don't think so. I never set it for anything. Just use CMAKE_PREFIX_PATH. If something is not found without pkgconfig that's a bug. QTDIR (self compiled qt), Do you need that for running ? For building it's not necessary. Use CMAKE_PREFIX_PATH. PATH so your self compiled stuff For building it's not necessary. Use CMAKE_PREFIX_PATH. is picked up, LD_LIBRARY_PATH if you want to run stuff, RPATH is not working for you ? This would be a bug. XDG_DATA_DIRS, KDEDIRS. This is for running, not for building, right ? 3. build order Isn't that the same as 1. ? No. kwebkitpart has to be build after kdelibs and before kdebase. Did you know that? Do you expect Joe NewKdeUser to know? The kdesupport order is much harder to get right. The strigi order? kdesupport and strigi are before KDE, as mentioned above. This doesn't make it easier, but it is not necessarily anymore in the scope of KDE. Quick. Order these smokegen, smokeqt, smokekde, qtruby, korundum. Ok. kdebindings is weird. 4. which branches, version from which repo (only relevant for some modules) You mean now with git or also with old svn ? Have you ever tried to compile ktorrent? I mean with old svn too. But i expect that to get a tad more difficult with git unless we get a real common branching names strategy. We really need that. Alex
Re: Initial support for kde_projects.xml in kdesrc-build
On Tue, Feb 1, 2011 at 2:58 PM, Michael Jansen i...@michael-jansen.biz wrote: On Tuesday 01 February 2011 20:35:27 Alexander Neundorf wrote: On Tuesday 01 February 2011, Michael Jansen wrote: On Tuesday 01 February 2011 19:53:40 Alexander Neundorf wrote: On Monday 31 January 2011, Aaron J. Seigo wrote: On Sunday, January 30, 2011, Michael Pyne wrote: Like I said, xml-support branch on kdesrc-build git. If you want to give _very_ cool. will the good news today never end? ;) serious question: once this is stabilized, can we make this the default recommended way of building KDE from git on techbase? pros that i can think of: * it would mean that we could cannibalize the docs for kdesrc-build for those pages on techbase * it would be a lot simpler to document than the current 7 headed hydra monster pages we have now :) The big thing is getting all the required dependencies built and installed, or do you see other things which are complicated in building KDE modules ? yes i do. 1. It is a lot of work. if you work on base and want to run trunk there is a myriad of modules to build to get a useful setup. kdelibs, kdepimlibs, then kdebase. So want Aaaron and me to miss out on kwebkit and scripting, and policykit and rekonq and ... konsole? How do you suppose to use your system without konsole. kdesupport? anyone ... perhaps qt from trunk or qtsoftware to get problems as early as possible? 2. environment variables (which and how to setup). Separate build environment from distro stuff that could interfere. CMAKE_PREFIX_PATH for finding stuff, and install your own stuff e.g. to /opt/mystuff/ Do you only compile stuff? Or do you run it too? Does strigi work for you? STRIGI_PLUGIN_PATH ... but i haven't tested for a while if it needed nowadays. Strigi would not work without it. PKG_CONFIG_PATH, QTDIR (self compiled qt), PATH so your self compiled stuff is picked up, LD_LIBRARY_PATH if you want to run stuff, XDG_DATA_DIRS, KDEDIRS. 3. build order Isn't that the same as 1. ? No. kwebkitpart has to be build after kdelibs and before kdebase. Did you know that? Do you expect Joe NewKdeUser to know? a. nope. kwebkitpart only depends on kdelibs! There are no requirements besides that. The previous requirement that you must build kwebkitpart before you compiled the konq-plugins, which have now been moved to kdebase, is now longer valid because of the addition of several Extentsion interfaces to the KParts API. As a result konq-plugins do not have direct dependency on kwebkitpart anymore in KDE = 4.6...
Re: Initial support for kde_projects.xml in kdesrc-build
On Tuesday 01 February 2011, Michael Jansen wrote: ... kdesupport? anyone ... perhaps qt from trunk or qtsoftware to get problems as early as possible? I was asking specifically about KDE stuff, i.e. everything starting with kdelibs, not stuff kdelibs depends on (which I also mentioned in my previous mail that this is not too easy to get set up, as you can see above). So those are not parts of the great big KDE Community and KDE SC? So you do not encourage KDE developers to work on that stuff too? I didn't want to say anything like that. But personally, I care for what is inside KDE. This is what gets released as KDE SC. If this doesn't build properly, I feel guilty. If a package outside KDE SC doesn't build properly, I provide help, but it's up to the respective authors. I must draw a line somewhere. 2. environment variables (which and how to setup). Separate build environment from distro stuff that could interfere. CMAKE_PREFIX_PATH for finding stuff, and install your own stuff e.g. to /opt/mystuff/ Do you only compile stuff? Or do you run it too? I don't get that far to actually run the stuff I've compiled... A lot of the work I do _for_ KDE is actually work _on_ CMake nowadays. That was no knock on you or your excellent work. You ask me what makes compiling kde so difficult and i tell you. Yes, no problem with that. I don't think so. I never set it for anything. Just use CMAKE_PREFIX_PATH. If something is not found without pkgconfig that's a bug. I have no idea what stops working if i unset it. But since i compile KDE with nearly all optional dependencies provided i am pretty sure somewhere in the chain something fails. If you find the place let me know. Do you need that for running ? For building it's not necessary. Use CMAKE_PREFIX_PATH. I always thought that PATH controls which qt version is selected if you have more than one (First qmake found). It was that way some time ago. And QTDIR IS USED in FindQt4.cmake. I don't reevaluate my finding every day so perhaps something changed. Ok. So when an executable is searched, it is searched in a set of default directories (as e.g. /usr/bin/) and in PATH. So setting PATH so that it points to the qmake you want works. CMAKE_PREFIX_PATH is more generic (and didn't exist in cmake 2.4.something). So you can set this too to make cmake find the Qt you want (not pointing to QTDIR/bin, but just to QTDIR). QTDIR is a variable specific to FindQt4.cmake, so it works too. So all three work, the most generic/powerful one is CMAKE_PREFIX_PATH. For building it's not necessary. Use CMAKE_PREFIX_PATH. is picked up, LD_LIBRARY_PATH if you want to run stuff, RPATH is not working for you ? This would be a bug. Yes it is. Even acknowledged by a cmake dev. Which doesn't make it magically work though. That is the lib64 issue you have, right ? I remember this one was tricky. And then there is that funny little gnome helper in okulars build system that totally break without LD_LIBRARY_PATH and sometimes works with LD_LIBRARY_PATH set. XDG_DATA_DIRS, KDEDIRS. This is for running, not for building, right ? I think it is for running mostly. Sometimes some stuff tries to find some policykit, dbus or whatever it was stuff using it. I fixed some of those wrongdoing modules a long time ago. I think there is currently noone misbehaving. Cool :-) Alex
Re: Initial support for kde_projects.xml in kdesrc-build
If you find the place let me know. No ... only if i am unable to fix it myself :)) . Do you need that for running ? For building it's not necessary. Use CMAKE_PREFIX_PATH. I always thought that PATH controls which qt version is selected if you have more than one (First qmake found). It was that way some time ago. And QTDIR IS USED in FindQt4.cmake. I don't reevaluate my finding every day so perhaps something changed. Ok. So when an executable is searched, it is searched in a set of default directories (as e.g. /usr/bin/) and in PATH. So setting PATH so that it points to the qmake you want works. CMAKE_PREFIX_PATH is more generic (and didn't exist in cmake 2.4.something). So you can set this too to make cmake find the Qt you want (not pointing to QTDIR/bin, but just to QTDIR). QTDIR is a variable specific to FindQt4.cmake, so it works too. So all three work, the most generic/powerful one is CMAKE_PREFIX_PATH. Then the 100 points question is: If all of them point to a directory with a qt installed (three different versions). Which one wins? a) CMAKE_PREFIX_PATH b) PATH c) QTDIR I remember more than one newbie losing his grip over not beeing able to convince cmake to pickup the right one. Can you answer it without looking at the cmake file? I can't. Yes it is. Even acknowledged by a cmake dev. Which doesn't make it magically work though. That is the lib64 issue you have, right ? I remember this one was tricky. Yes. But there are some executables build and the run during a build that need to pickup the right libs too. I am not sure all of them are doing it right or if there is a right way to do it. The one gnome helper i can point you too is not using cmake. And then there is that funny little gnome helper in okulars build system that totally break without LD_LIBRARY_PATH and sometimes works with LD_LIBRARY_PATH set. Mike
Re: Initial support for kde_projects.xml in kdesrc-build
On Tue, Feb 1, 2011 at 4:14 PM, Michael Jansen i...@michael-jansen.biz wrote: a. nope. kwebkitpart only depends on kdelibs! There are no requirements besides that. The previous requirement that you must build kwebkitpart before you compiled the konq-plugins, which have now been moved to kdebase, is now longer valid because of the addition of several Extentsion interfaces to the KParts API. As a result konq-plugins do not have direct dependency on kwebkitpart anymore in KDE = 4.6... But that requirement came and went without a great announcement. Previously you had to compile kwebkitpart before kdebase so you got the ability to use webkit with konqueror. But that is just it... There never was any requirement of compiling kwebkitpart before kdebase, ever! I think perhaps you are confusing konq-plugins with being in kdebase ? But the konq-plugins prior to the trunk for KDE 4.7 being opened were located in extragear/base and not kdebase. So I do not know where you got the impression of such dependency. It did not exist. The optional dependency that existed was that some of the konq-plugins linked directly against kwebkitpart if available. As such you needed to have compiled and installed kwebkitpart to activate support for it in some of these konq-plugins. And that was the ugly dependency that was solved by the changes I described in my original response. Anyhow, I guess this is not really the point of your discussion, but a rather a bad example you used...
Re: Initial support for kde_projects.xml in kdesrc-build
On 01.02.11 23:14:26, Michael Jansen wrote: Do you need that for running ? For building it's not necessary. Use CMAKE_PREFIX_PATH. I always thought that PATH controls which qt version is selected if you have more than one (First qmake found). It was that way some time ago. And QTDIR IS USED in FindQt4.cmake. I don't reevaluate my finding every day so perhaps something changed. Ok. So when an executable is searched, it is searched in a set of default directories (as e.g. /usr/bin/) and in PATH. So setting PATH so that it points to the qmake you want works. CMAKE_PREFIX_PATH is more generic (and didn't exist in cmake 2.4.something). So you can set this too to make cmake find the Qt you want (not pointing to QTDIR/bin, but just to QTDIR). QTDIR is a variable specific to FindQt4.cmake, so it works too. So all three work, the most generic/powerful one is CMAKE_PREFIX_PATH. Then the 100 points question is: If all of them point to a directory with a qt installed (three different versions). Which one wins? a) CMAKE_PREFIX_PATH b) PATH c) QTDIR I remember more than one newbie losing his grip over not beeing able to convince cmake to pickup the right one. Can you answer it without looking at the cmake file? I can't. No of course not because you don't know how QTDIR is being used. But thats rather a problem of the FindQt4.cmake module not documented where it uses the QTDIR variable. Once you know it puts that into the PATHS option the rest is a mere look at the cmake manual which lists the order in which it searches for stuff. In particular in your case it'll find the qmake in CMAKE_PREFIX_PATH. Yes it is. Even acknowledged by a cmake dev. Which doesn't make it magically work though. That is the lib64 issue you have, right ? I remember this one was tricky. Yes. But there are some executables build and the run during a build that need to pickup the right libs too. I am not sure all of them are doing it right or if there is a right way to do it. The one gnome helper i can point you too is not using cmake. Well, in kde modules the executables being built will have rpath set too, so that should work - in theory. But as I don't know what exactly Alex and you are talking about here and what your setup is I'll shut up :) Andreas -- You will be given a post of trust and responsibility.
Re: Initial support for kde_projects.xml in kdesrc-build
On Sunday, January 30, 2011, Michael Pyne wrote: Like I said, xml-support branch on kdesrc-build git. If you want to give _very_ cool. will the good news today never end? ;) serious question: once this is stabilized, can we make this the default recommended way of building KDE from git on techbase? pros that i can think of: * it would mean that we could cannibalize the docs for kdesrc-build for those pages on techbase * it would be a lot simpler to document than the current 7 headed hydra monster pages we have now :) cons: * it means encouraging people to get and learn one more tool to get involved with KDE that still seems easier than the current recommended practices, and so i expect it to be a win rather than a net loss. -- Aaron J. Seigo humru othro a kohnu se GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA EE75 D6B7 2EB1 A7F1 DB43 KDE core developer sponsored by Qt Development Frameworks signature.asc Description: This is a digitally signed message part.
Re: Initial support for kde_projects.xml in kdesrc-build
On Monday, January 31, 2011 17:48:38 Aaron J. Seigo wrote: On Sunday, January 30, 2011, Michael Pyne wrote: Like I said, xml-support branch on kdesrc-build git. If you want to give _very_ cool. will the good news today never end? ;) serious question: once this is stabilized, can we make this the default recommended way of building KDE from git on techbase? Sure, but I won't be pushing that on TechBase unless asked to do so. I prefer not to evangelize my script too much although at the same time I understand the desire for a more canonical method for building KDE. pros that i can think of: * it would mean that we could cannibalize the docs for kdesrc-build for those pages on techbase Although I've worked hard on them, I think the current docs aren't exactly what's needed for TechBase. There should be many more Here's how to do this and less Here's the exhaustive list of every stupid option. Not that it's hard to fix on TechBase, but any docs cannibalization should probably be limited to a link from TechBase to docs.kde.org for those who want to know all the options. * it would be a lot simpler to document than the current 7 headed hydra monster pages we have now :) I think I agree here. ;) cons: * it means encouraging people to get and learn one more tool to get involved with KDE And because of that I think even if we make it the recommended way to perform the build, that we should still have the manual instructions fully documented on TechBase. Regards, - Michael Pyne signature.asc Description: This is a digitally signed message part.
Re: Initial support for kde_projects.xml in kdesrc-build
On Monday, January 31, 2011, Albert Astals Cid wrote: * There is black magic happening behind your back and once something breaks you won't know how to fix things by yourself. we can and should document how to do all the things by hand as well for such situations. but it would be nice if the default recommendation was something that a new contributor could use to get a full KDE build going with just a few minutes effort on their part. -- Aaron J. Seigo humru othro a kohnu se GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA EE75 D6B7 2EB1 A7F1 DB43 KDE core developer sponsored by Qt Development Frameworks signature.asc Description: This is a digitally signed message part.
Re: Initial support for kde_projects.xml in kdesrc-build
On Monday, January 31, 2011 18:19:12 Albert Astals Cid wrote: cons: * There is black magic happening behind your back and once something breaks you won't know how to fix things by yourself. Although it is definitely true that kdesrc-build hides what it's doing unless you delve into either the --pretend output or the log files (where the command run is displayed at the top of every log file), this is also a pro: pros: * There is black magic happening behind your back so that users who are unwilling/unable to navigate gcc/make/cmake can still build and test bleeding- edge versions of KDE despite their lack of CLI mastery. Anytime you add a layer to a working system there is usually a pro of this makes me do less work and a con of now I forgot how it works (e.g. moc, high level programming languages in general, etc.) I certainly don't disagree with the con you mentioned, but I do think that the benefit in increased testing coverage outweighs the concern with black magic, especially since I take great pains (and have for years) to have kdesrc-build operate as much like you or I would do the build as possible. For instance even after using kdesrc-build on my source tree for years I can go to svn or git modules and run the standard update command (even git pull) and everything just works. I can go to the build directory and run make or cmake-gui and things just work. When I'm worried about what kdesrc-build is about to do, I can pass the --pretend flag and it shows the command line for about 95% of the commands it would run. In short it is (my idea of) a bum- standard build system, or as close as I can get it in an automated script. Regards, - Michael Pyne signature.asc Description: This is a digitally signed message part.
Re: Initial support for kde_projects.xml in kdesrc-build
On Mon, Jan 31, 2011 at 19:08, Michael Pyne wrote: On Monday, January 31, 2011 18:19:12 Albert Astals Cid wrote: cons: * There is black magic happening behind your back and once something breaks you won't know how to fix things by yourself. For instance even after using kdesrc-build on my source tree for years I can go to svn or git modules and run the standard update command (even git pull) and everything just works. I can go to the build directory and run make or cmake-gui and things just work. When I'm worried about what kdesrc-build is about to do, I can pass the --pretend flag and it shows the command line for about 95% of the commands it would run. In short it is (my idea of) a bum- standard build system, or as close as I can get it in an automated script. I was about to make this same point. When I first started KDE development, I tried to set up my own build environment. After one unsuccessful attempt and then one somewhat successful attempt, I learned about kdesvn-build. It got me up and running with trunk after 5 minutes of configuration and a single build run. While I'm sure I learned some things from my manual setup attempt, I'm pretty sure that I learned more from having a working build environment to play around in. And as Michael said, that's the beauty of kdesrc-build. You are free to play around with your checkouts and build directories and things will generally keep working. For example, KDevelop and kdesrc-build will happily share a build directory and reuse each other's CMake caches. There's certainly value in understanding the details of the manual guides currently in Techbase, but honestly I think they'd be easier to learn if one already had a kdesrc-build setup to work with. Parker
Initial support for kde_projects.xml in kdesrc-build
Hi all, Just a quick email as I'm already late getting to bed, but I just wanted to let you know (in case you're interested) that I've just committed initial support for the kde_projects.xml database to kdesrc-build (in git; xml-support branch). It requires using a use-xml-modules option in a module-set (where you'd use the existing use-modules option). e.g. module-set use-xml-modules kdebindings krita-extensions konsole end module-set since the repository information for an XML module is encoded as part of the XML there's really not much else to configure as far as finding the git repositories goes. Other options can still be set as normal. If a module doesn't show up where you expect in your kdesrc-build --pretend output, make sure you didn't already have it buried somewhere :P (e.g. that konsole example I gave doesn't show up on my system, since it was already being built earlier). Whatever identifier you give is searched in the XML tags module, component and project, and repositories are recursively found from there. One exception is that if the component or module contains both its own repo, and other children with repos, the repo which is a direct child is preferred, and the childrens' repos are all ignored. (I think this is desired behavior with calligra, unless the calligra repo is essentially empty, I haven't had time to delve into that). There is no dependency tracking. There is a repo setup for that kind of metadata so it will work well enough someday, but until then modules are built in the order that they show up in the XML. I also haven't coded in warnings for module identifiers that are not unique in the XML. If there are non-unique identifiers and you try to build it, your guess on the module that actually gets built is probably as good as mine. If this makes you wary, you should be able to specify a full path just fine (e.g. kde/kdebindings, extragear/utils/kdesrc-build, etc.) My roadmap such as it is, is that when this all works well enough, to move effectively all defaults regarding what modules to build to the build-setup repo I was referring to earlier, and then changing the defaults there should in theory continuously update the defaults for deployed kdesrc-builds. There would also be some mechanism to instead have an exact configuration like you can do now. Like I said, xml-support branch on kdesrc-build git. If you want to give it a shot I'd appreciate it, if not that's fine too. Do keep in mind that I will be once again extraordinarily busy over the working week so if I horribly broke something I may not be able to fix it til the weekend. Happy building! Regards, - Michael Pyne signature.asc Description: This is a digitally signed message part.
