ports/116058: Update: x11-themes/gtk-qt-engine to version 0.8

[Dave Grochowski]

The following reply was made to PR ports/116058; it has been noted by GNATS.

From: Dave Grochowski <malus.x at gmail.com>
To: Danny Pansters <danny at ricin.com>
Cc: bug-followup at freebsd.org
Subject: Re: ports/116058: Update: x11-themes/gtk-qt-engine to version 0.8
Date: Tue, 04 Sep 2007 20:25:35 -0400

 Hey,
 
 Danny Pansters wrote:
 > <snip>
 >   
 >> 1. GTK_LIB_DIR should be set to "${LOCALBASE}/lib".
 >>
 >> 2. Similarly, KDE3_LIB_DIR should be set to "${LOCALBASE}/lib".
 >>
 >> 3. You cannot pass in GTK_PREFIX, GTK_LIB_DIR, and KDE3_LIB_DIR like
 >> that. The values for those are actually pulled from pkg-config. Any
 >> parameters passed in will be overwritten anyway when the calls to
 >> pkg-config are made.
 >>     
 >
 > Ooow, ok. Yes you're right. Hehe.
 >
 >   
 >> Does it make more sense to pass in the values for those or just use
 >> pkg-config to figure them out? The former will require a little more
 >> work to achieve, either with some sed magic or a patch.
 >>     
 >
 > I don't know much about pkg-config (gnome stuff ;-), but I think that 
 > considering that the package will only work if installed in the right place, 
 > this is the kind of package where it's better to not pretend. It *must* be in 
 > the gtk theme dir, it *must* be in the kcm dir. PREFIX is useful for packages 
 > that are pretty much self hosted, here it's probably better to not use it at 
 > all. If a user would want a large body of software (kde,gnome) working 
 > together installed in a non standard place they would/should change LOCALBASE 
 > or maybe DESTDIR.
 >
 > Besides, since pkg-config seems to do the right thing, I don't see a reason 
 > not to just use what it comes up with unless it breaks something. They 
 > probably thought harder about it than I did.
 >
 >   
 >>> - re-add lib dependency on kdecore. The kcm module build really requires
 >>> kdecore. And I think also for running.
 >>>       
 >> Whoops, that was an accident.
 >>     
 >
 > Wonder why I never used USE_KDEBASE_VER there, well, let's do it now!
 >
 >   
 >>> - I like the CMAKE_ARGS way of passing CXX and friends that you used,
 >>> kept that in, also used a CMAKE variable for the cmake path, which I
 >>> expect a new bsd.cmake.mk to so in the near future (as well as probably
 >>> providing a canned-in way to add common cmake args).
 >>>       
 >> I was going to suggest making it:
 >>
 >> CMAKE?=          ${LOCALBASE}/bin/cmake
 >>     
 >
 > Yes, that's better.
 >
 >   
 >> However, I suppose the Makefile will be edited anyway after the
 >> introduction of bsd.cmake.mk, so the point is irrelevant.
 >>     
 >
 > Well, I'm not saying there will be one, rather that I think eventually there 
 > will be one (with kde4 and all).
 >
 >   
 >>> - I noticed you using the pre-build target, while you probably wanted to
 >>> override the do-configure target. To do that you use do-configure and set
 >>> HAS_CONFIGURE=yes. Well, that's what I did at least :)
 >>>       
 >> Ok, makes more sense.
 >>
 >>     
 >>> I tested on tinderbuild/STABLE and also tested building with gcc42, and
 >>> limited runtime testing (that is: look at abiword's GUI)
 >>>
 >>> Thanks!
 >>>
 >>> Dan
 >>>       
 >> Well, your update to the port works fine for me as well.
 >>
 >> Sincerely,
 >> Dave Grochowski
 >>     
 >
 > Attached is a reworked and simplified version (e.g. rely on pkg-config since 
 > it seems to be doing its job alright) of the port, now also using 
 > USE_KDEBASE_VER as should.
 >
 > Thanks,
 >
 > Dan
 >   
 The patch looks good! I think you should still pass in 
 ${CMAKE_INSTALL_PREFIX}, since that is not automagically determined from 
 pkg-config (I think it is determined when cmake is compiled and 
 installed). However, it might be pointless, since I think it only 
 determines the install locations for the internationalization stuff. Thanks!
 
 Sincerely,
 Dave Grochowski