Russell E Owen wrote:
It turns out my wx-config was in:
not a location I'd ever have expected or would want to add to my $PATH (and not easy to find -- I had to use a special file finding utility to find it).
No wonder I was having problems!
Do you know who produced the wxPython installer package?
Robin Dunn builds those himself.
If so, please tell me or feel free to forward this message (edited as you see fit). I want to suggest they put links to binaries in one of:
I think the former is the right choice if the associated wx C++ libraries (as installed by wxPython) are accessible to C++ users.
They are really intended to be used specifically by wxPython. Often they are slightly different versions. I now when I've used wx for C++, I've used different libs.
Otherwise if it's really a python-private sort of thing then it should probably be the latter.
I think so. But there is a problem there, too. As I mentioned, you can have different versions of wxPython installed at once, so which one would put it's wx-config there?
Also, /Library/Frameworks/Python.../bin is the default locations for binaries on OS-X, set by dist-utils. On other systems, it's set to /usr/local, or who knows? In that case, putting wx-config there could clash with both C++ wx installations, and wxPythons used for different versions of python -- there's just no easy way. At least this way, when you pick that wx-config, you KNOW you've got the one you want.
As far as MPL is concerned, we could write a little code that would search for the default wxPython, and find wx-config there.
However, the better solution is really to get rid of the compile-time dependence on wx -- that's a problem anyway. For instance, I'm not sure we should make the pythonmac binary depend on wxPython 2.7 -- that is a development version -- 2.6.3 may be a better choice.
If only we all didn't have other things to do...
Christopher Barker, Ph.D.
NOAA/OR&R/HAZMAT (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception