On Tue, Jun 28, 2005 at 01:59:04PM +0000, John R. Culleton wrote: > On Tuesday 28 June 2005 04:01 pm, Manish Singh wrote: > > On Tue, Jun 28, 2005 at 10:46:12AM +0000, John R. Culleton wrote: > > > On Tuesday 28 June 2005 10:13 am, John R. Culleton wrote: > > > > On Tuesday 14 June 2005 08:42 pm, Carol Spears wrote: > > > > > mr. culleton, i am going to respectfully ask the reason that after > > > > > all of this time you are not running a cvs version of gimp? you seem > > > > > overdue for this. > > > > > > > > With other packages there is an overnight snapshot of the CVS, > > > > bundled as tarball. Does such a facility exist for Gimp? Where? > > > > > > > > > if you find pygtk and get python running on gimp, i would like to > > > > > have your feedback about my silly little script writing attempts. > > > > > > > > Still struggling with pygtk. More later. > > > > > > Happy to report that they pygtk problem has bee ameliorated. I > > > found pygtk-2.0 and installed it. Then after a little cut-and > > > try I copied pygtk-2.0.pc to /usr/lib/pkgconfig. That bypassed > > > the error messages. > > > > > > Why the pygtk make install didn't do this automatically I don't > > > know. > > > > Because you're supposed to set PKG_CONFIG_PATH in the environment to > > point to where the .pc file lives, instead of copying it. > > > Fine. so if I have 148 packages, then this environment variable > is set to all 148 locations? Two facts intrude:
Well, if you configure all 148 packages into separate prefixes, then yeah. But that would be silly. On one of my development machines, I build HEAD versions of gimp, pygtk, gtk+ and it's dependents. They go in *one* prefix, and PKG_CONFIG_PATH contains *one* path to find them. They don't belong in /usr/lib since I don't really want to use unstable libraries for the entire system. > 1. 148 other files with the suffix .pc reside in the directory > previously mentioned. Which are installed by the system package manager. > 2. The environmental variable you mention doesn't appear to exist > on my machine currently. I used the "set" command with no > parameters and it did not show up on the list. LD_LIBRARY_PATH doesn't exist on a system by default either, but that's how you configure the runtime linker to look in non-default locations. PKG_CONFIG_PATH is similar in concept, but for compile time stuff. > Sorry folks, I am an old line pragmatist. The quickest and surest > way to make something work is the one I will choose. Instead of > expanding the list of locations searched just for a single > package used by a single application, moving the required file > to a place where the system will find it makes more sense to me. > It is simple, it is sensible and it is robust. It violates the principle that stuff in /usr should only be controlled by the package manager. If you'd used a pygtk package for your system instead of building your own (assuming one exists), the .pc file would indeed be in /usr. If you're building stuff by hand, add the appropriate stuff to your environment based on what --prefix you choose. It's not really complex. -Yosh _______________________________________________ Gimp-user mailing list Gimp-user@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-user
