I'd like to use this bug to keep track of All changes that we should make to kde's configure scripts and to the ebuilds to really use our provided USE flags. A lot of kde's configure scripts checks the system for various libs present and enable various features depending on these checks. The problem is that it's not possible to disable a lot of these checks, and so we cannot use myconf="`{use-with|use-enable} $USEFLAG [$CONFIGUREOPTION]`". This will bring some problem on how portage manage the ebuilds; for example we can have USE=-vorbis, but if we have libvorbis installed the support will be enabled in kde. When we do a "depclean", emerge will remove it as the USE flag is disabled and this will broke kde as it cannot find that lib anymore. As some of us has CVS access to the kde repository, we should commit them to. The standard way I change the configure.in.in files is this: AC_ARG_WITH(FEATURE,AC_HELP_STRING([--with-FEATURE],[Enable FEATURE support [default=check]]),[FEATURE_test="$withval"],[FEATURE_test="yes"]) and then make the check depending on this: if test "x$FEATURE_test" = "xyes" ; then THE CHECK fi This would be harmfull, has the standard behavior, if the configure option isn't specified, will be the same (do the check). One time we applied these changes we can update our ebuilds to use them with the standard "use-with" and "use-enable" functions.
I added the check for hal used in "kdebase/kioslave/media". In this way we can disable the compilation of the hal backend if the (global) use flag hal is disabled. We need at least sys-apps/dbus-0.22-r3 for the qt support.
Created attachment 51259 [details, diff] kioslave-media-configure.in.in.patch Needs to be commited upstream.
Created attachment 51260 [details, diff] kdebase-kioslaves-3.4.0_beta2.ebuild.patch The same should be done with the kdebase ebuild.
Another new one, this time in kdelibs/kimgio. Add configure flags for checks on tiff, openexr and jasper(jpeg2k).
Created attachment 51272 [details, diff] kdelibs-kimgio-configure.in.in.patch Needs to be committed upstream.
Created attachment 51273 [details, diff] kdelibs-3.4.0_beta2.ebuild.patch
Comment on attachment 51259 [details, diff] kioslave-media-configure.in.in.patch Committed upstream
Comment on attachment 51272 [details, diff] kdelibs-kimgio-configure.in.in.patch Committed upstream
Created attachment 51336 [details, diff] kdelibs-kdecore-configure.in.in.patch Adds a configure flag that let us explicity enable/disable the use of libidn. Needs to be commited upstream.
These days, I put together a set of patches to fix the configure scripts of arts kdelibs and kdebase. They can be found here: http://dev.gentoo.org/~greg_g/kde-configure/ (I intend to slowly add patches for the other modules there) Can you take a look at it? My goal would be to push out a revision bump of arts, kdebase, kdelibs with these fixes later today (together with the fix for bug 94872, while we are at it). This would close at least bug 92433 (which could affect many people) and bug 74121. Then, maybe some of us with kde svn access could commit them upstream?
The patches above are now in portage.
I'm glad to announce that this effort is complete. At http://dev.gentoo.org/~greg_g/kde-configure/ you can find all the patches for KDE configure scripts. I any of us with a SVN account feels like committing them please let me know, otherwise I will post them to bugs.kde.org tomorrow.
I'll plan to commit them, Greg.
Thanks a lot Caleb. FYI, all the patch apply also to the 3.4 branch, except the poppler one (as poppler is not in 3.4) and except the gnokii one (there's a 3.4 version on the page). However probably the huge kdemultimedia patch is not much suited for the branch? (even if I spent a lot of time to see if it did the right thing in many different situations, as for the other patches).
Okay, they're committed to trunk. If nobody yells at me, I'll merge them into 3.4 in a couple of days.
Excellent! You can also do a svn rm on these four files that are now empty: kdemultimedia/kioslave/audiocd/configure.in.bot kdemultimedia/kioslave/audiocd/configure.in.in kdemultimedia/kmix/configure.in.in kdemultimedia/kaudiocreator/configure.in.in
To summarize: For 3.5 the situation is nearly perfect: all the patches have been applied except for two: http://dev.gentoo.org/~greg_g/kde-configure/configure-fix-kdebase-openexr.patch http://dev.gentoo.org/~greg_g/kde-configure/configure-fix-kdesdk-db.patch These should be commited to trunk and the new branch: branches/3.5 The only test I know of that hasn't a configure switch is for meanwhile in kopete. I will look into making a patch for that when I find some time, too. For 3.4: all the patches above, except the big kdemultimedia patch, are included in our ebuilds. In addition the patch for kdeartwork also includes some code to fix bug 98819, which was submitted in http://bugs.kde.org/show_bug.cgi?id=105748. Comment #16 still holds, someone should do a cleanup of those four files. for KDE 3.5 akode was moved from kdemultimedia to kdesupport, I will take a look to see if this requires some cleanup of the configure.in.in there.
I've got another patch for the 3.5 branch: check for the newly introduced ACL support: http://www.gentoo.org/cgi-bin/viewcvs.cgi/*checkout*/kde-base/kdelibs/files/kdelibs-3.5_beta1-configure-acl.patch?rev=1.1&content-type=text/plain Caleb, have you got a minute to do the commits? To recap: commit to branches/3.5: http://www.gentoo.org/cgi-bin/viewcvs.cgi/*checkout*/kde-base/kdelibs/files/kdelibs-3.5_beta1-configure-acl.patch?rev=1.1&content-type=text/plain http://www.gentoo.org/cgi-bin/viewcvs.cgi/*checkout*/kde-base/kdebase/files/kdebase-3.5-configure-openexr.patch?rev=1.1&content-type=text/plain http://www.gentoo.org/cgi-bin/viewcvs.cgi/*checkout*/kde-base/kdesdk/files/kdesdk-3.5-configure-db.patch?rev=1.1&content-type=text/plain run "svn remove" in branches/3.5 on kdemultimedia/kioslave/audiocd/configure.in.in kdemultimedia/kmix/configure.in.in kdemultimedia/kaudiocreator/configure.in.in
Yep, lemme make a post to kde-core-devel first.
Finally we can consider his bug fixed, if new issues arise we can deal with them in new bugs. Closing.