On Sun, 29 Jan 2012 16:45:28 +0100 "roman" <lists@...> wrote: > > On Sun, January 29, 2012 16:38, E. Liddell wrote: > >> You are right about the organized effort. > > > > Yeah. Problem is that no one seems to want the job of organizer > > (including > > me!). > Well.. i don't want it because i don't really have enough knowledge about > c/c++,cmake,automake etc.. to be competent enough. > Also the mix from automake/cmake seems to be the biggest to not > remove/rewrite the eclasses from ground up. > Maybe we should start with a clean cmake-only overlay to get things > streamlined? It might take some time to get everything in there, but seems > to be the only clean solution. That means we're not going to get anywhere until Serghei finishes porting, though, which means several more versions of Trinity (and likely a couple of years) will go by. I'm not good with C/C++ or their build systems either--I'm a Java/Perl/PHP programmer by inclination. The most annoying part is that I'm very, very close to getting this working (at least for x86). I got half of kdetoys to work, frex, but the other half is getting hit with what I think is an --as-needed breakage in kdelibs. If we could rope in even one competent dev . . . > >>The ebuild also came down to the following error which seems > >> to be an code-error? > >> > >> kxinewidget.cpp:2641:66: error: invalid conversion from â€˜const char* > >> const*â€™ to â€˜char**â€™ [-fpermissive] > > > > Looks like a code error to me, too . . . Pointer casting like this is one > > of > > the reasons I hate C/C++--in a sane language, that would never have > > compiled to begin with, and the original coder would have had to fix it. > > > > Say, which arch are you on? > I'm on amdfam10. *Ah.* While my actual machine is also amdfam10, the virtual machine I've been using to test Trinity is set up as x86, not x86_64. So we may be seeing a pointer cast that works under 32bit but breaks with 64bit. (And if I were just a bit better with this, that might be enough to tell me how to fix it . . . Grrr.) > BTW it also seems that there are problems detecting the correct qt-path > when qt4 is installed (just tried installing sopcast, to watch the > handball-em final, it's not being broadcasted in germany;( ). I think there have been reports of that being a problem on other distros as well, probably from the Slackware packager. It might be possible to filter the QT4 directory out of the path before building (it doesn't seem to install to /lib, thankfully), but it's going to take some work to figure out how.