Python34 include directory problems

[Michael Dickens]

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