Out of curiosity, I wrote this little script today; and discovered that I have pkg-config files in 78 different directories. Granted, quite a few of those are in build trees. But it's still a bit excessive. It would be simple enough to write a script to move them all into one of the directories in the default pkg-config search path. But can I keep future installations from scattering the files all over the place again? If I add "PKG_CONFIG_PATH=" to .bashrc will future builds honor that or just override it? Not every configure script accepts a pkg-config-path argument so it can't always be done manually.

I'm getting more and more into installing from source. I'd like to learn how I can keep control of files like this during builds so I can keep track of where everything is. Ideally, I want all my pkg-config files in one or two places, all my doc files in one or two places, and so on down the line.

I ran your script here, and found 11 directories. I compile, but it is not my practise to leave build trees around. Archives are backed up, packages made, & build trees removed. From my list, I discounted the following categories of directory
1. Anywhere in $PKG_CONFIG_PATH - where .pc files actually belong.
2. Build trees - where .pc files actually belong.
3. Temporary install dir(I use just one) for making packages - where .pc files actually belong.
4. Package documentation directories. This is duplication and they could be deleted, though I wouldn't bend so low to collect so little in the way of free space :-).
5. Package trees like Qt with it's own lib/ subdir although the comment on 4 applies here too if they installed it in a sensible place, and didn't insert the directory in $PKG_CONFIG_PATH.

Remove the build trees if you want space - I wouldn't worry about .pc files.

Thanks for the tips. I'll be putting them to use. I'm not worried so much about saving space as I am worried about the system not finding things I know I have. I'm regularly getting errors telling me I should move a package's pc file to somewhere in the path because 'which', for example, doesn't see it. Rather than add dozens of new paths to the PKG_CONFIG_PATH env I figured it would be better to find the files and move them. I ended up expanding the above script to do just that. I did 'mv -n' to keep from moving duplicates. I also ignored quite a few directories as you mentioned. So hopefully I haven't screwed up again.

which doesn't search $PKG_CONFIG_PATH. It just searches for executables in $PATH.

Right, my mistake. It probably was pkg-config. Still, it's annoying when the machine is telling me I don't have a program that I know I have.

There is the 32/64 bit problem. My PKG_CONFIG_PATH doesn't have /usr/lib/pkgconfig in it. That's strictly 32bit on Slackware, but there's a bundle of .pc files there. It does have nonexistent (yet) directories in /usr/local. Some things hide .pc files in /usr/share/pkgconfig; Is that in your PKG_CONFIG_PATH?

It is. But I think I put it there.

Then go through them on an individual basis, & search for each "missing" package. In some cases you may have to generate a file yourself. I think you get away with the name, description & version.

You could get away with that little bit of information. But .pc files also carry more information that can be helpful. I'm not sure how easy it would be to create that information from scratch.