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.
Gimp-user mailing list