Python34 include directory problems

[Michael Dickens]

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'))"
}}}

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

On Mon, Jul 6, 2015, at 01:51 PM, Joshua Root wrote:
> For background, you introduced the current behaviour in
> <https://trac.macports.org/changeset/105101>. The reason for the
> globbing is that various abiflags [1] may be present in the directory
> name depending on configure-time options.
> 
> I don't think we would ever be building without pymalloc, and we never
> enable pydebug. That leaves --with-wide-unicode as enabled by +ucs4,
> which is a hugely problematic variant (as well as breaking binary
> compatibility, it also broke pyobjc last I heard) and has been removed
> from later python versions' ports.
> 
> So, standardising on pymalloc only is probably right.
> 
> I'm not sure why you're seeing a python 3.x include dir without the m
> suffix though. That sounds like a bug in whatever is installing the
> files in there.
> 
> [1] https://www.python.org/dev/peps/pep-3149/#proposal