On Mon, Jul 6, 2015, at 03:06 PM, Joshua Root wrote: > On 2015-7-7 04:45 , Michael Dickens wrote: > > I must have a short memory; I have no recollection of doing that commit. > > Thanks for the explanation of why the 'm' or 'u' or 'd' or whatever; I > > had forgotten that too. Reading through that PEP, seems like we can use > > the Python sysconfig variable 'INCLUDEPY' to determined the include > > install location; it works with both 2.7 and 3.4 quite nicely: > > {{{ > > pythonX.Y -c "import sysconfig; > > print(sysconfig.get_config_var('INCLUDEPY'))" > > }}} > > Yes. It doesn't work with 2.6, but that's not really a problem. Remember > though that we need to be able to produce a value for ${python.include} > when evaluating portfiles before any dependencies, including pythonX.Y, > have been installed.
Yes, quite true. Not quite sure how to handle this beyond creating a new variable, say python.abiflags, which is set by default to '' for < 30 and 'm' for >= 30; then, if 'pythonX.Y' exists, use it as per the above to get actual info. Not sure if this'll work, but I'll try it. > > It looks like the culprit is dbus-python (owned by mcalhoun and quite > > out of date; port version 1.2.0 and current stable release of 1.8.18); > > in the configure.args it adds: > > {{{ > > --includedir=${python_prefix}/include/python${python_branch} > > \ > > }}} > > without the 'm'. Thus, because of the code I added to the Python > > PortGroup, this directory will be reused as the place to install > > includes for python3.4 for ports that use that setting (not all do). > > Hence why sip.h was installed there, since it was installed -after- > > dbus-python34. - MLD > > OK, so that should be fixed and then some rev bumps will be needed. I created ticket < https://trac.macports.org/ticket/48273 > for the direct issue. I didn't create a ticket for the rev update. - MLD _______________________________________________ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev