You can clone with
HTTPS or Subversion.
Artem mentioned this would be useful - I'll look into implementing.
[tomh] What do you mean exactly? PKG_CONFIG_PATH is an environment variable so unless scons is doing something very odd and explicitly removing it will automatically propagate and be picked up by the calls scons makes to pkg-config.
In fact I'm pretty sure it does work as I've used it with mapnik I believe.
[springmeyer] Yes, as long as SCons is in the default USE_USER_ENV mode it should inherit this environment variable:
I guess my interest here is if multiple versions of pkg-config are on one system. Should we allow the user to configure which pkg-config program to point at (like we do for xml2-config and freetype-config), or what is the best route?
[tomh] I have to wonder what kind of crazy system has multiple copies of pkg-config installed... Plus setting PKG_CONFIG_PATH has nothing to do with the version of pkj-config that is used, it controls where pkg-config looks for .pc files.
[springmeyer] Yes, I agree, Macports (on osx) is crazy - it keeps its own copy of everything which makes me question its viability as an approach for users to install Mapnik dependencies, particularly Cairo. In this case pkg-config is duplicated because it also comes pre-installed in /usr/bin on 10.5.
[tomh] Well if you really need to be able to say which pkg-config to run then obviously an scons option is needed, but I would avoid calling it PKG_CONFIG_PATH or things will get very confused.
We should really be using pkg-config to find more things in fact (GDAL for example, instead of just looking in /usr/local...) and pg_config to find Postgres, and...
[springmeyer] Okay, will do.
For GDAL and Postgres, do you think pkg-config should be used over the gdal-config and pg_config executables? Any preference?
[tomh] I didn't realise there was a gdal-config. I don't have any particular preference which is used in that case - it may be that gdal-config has been around longer? Postgres doesn't seem to have pkg-config support so pg_config is the only option there.
Both libpng and libicu (as icu) have pkg-config support as well in fact.
[springmeyer] pushing off - should be looked at in concert with #214
Also to clarify, if PKG_CONFIG_PATH is set and SCons is configured to read in the users environment then os.environ['PKG_CONFIG_PATH'] to be pushed into SCons's env['ENV']['PKG_CONFIG_PATH']. So it is not available in the base environment.
However Tomh is absolutely right that irregardless of what SCons knows about/carries in its ENV() the pkg-config should pick up the $PKG_CONFIG_PATH when SCons shells out to it.
[springmeyer] Just had a chance to test and confirm that when PKG_CONFIG_PATH is properly set in the user's environment the pkg-config calls inside scons are informed by the variable.
so, closing this ticket as I recently hardcoded the inheritance of SCons ENV from the users ENV (which I had previously made an option during testing) so this should work in all cases.
If at any time we decide not to have the SCons environment inherit from the users ENV then a bit of code like this will maintain the PKG_CONFIG_PATH variable:
env["ENV"]["PKG_CONFIG_PATH"] = os.environ.get("PKG_CONFIG_PATH")
[springmeyer] r1187 removes the creation of a SCons environment that inherits from the user's os.environ. Reopening this ticket so I remember to test the need for the above mentioned custom support for PKG_CONFIG_PATH before the 0.6.1 release.
[springmeyer] looks like PKG_CONFIG_PATH should still be picked up from the environment, but in r1201 also added the ability to specify/override as a SCons variable, allowing the benefit of both fine-tuning of the path pkg-config looks to and the ability to store the path in the 'config.py'.