This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author sydefekt
Recipients dstufft, eric.araujo, paul.moore, steve.dower, sydefekt, tim.golden, zach.ware
Date 2020-04-02.23:24:48
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1585869888.82.0.151743130482.issue40158@roundup.psfhosted.org>
In-reply-to
Content
In testing the fix, another issue has arisen. It appears the specified expression will never yield a usable path.

Expression 1:
$([msbuild]::GetDirectoryNameOfFileAbove($(MSBuildThisFileDirectory), "python_d.exe"))

Expression 2:
$([msbuild]::GetDirectoryNameOfFileAbove($(MSBuildThisFileDirectory), "python.exe"))

The package has the abridged structure of:

┌─ build
│  │
│  └─ native
│     │
│     └─ python.props
│
└─ tools
   │
   └─ python.exe


Based on this hierachy, neither exe will resolve because they do not have the same common ancestor. Additionally,
I found that "python_d.exe" is always assumed for "Configuration=Debug", but "python_d.exe" does not exist in
the package (that I could find). I'm not sure if this means the path is wrong, "python_d.exe" was accidentally
omiitted, or this property assignment simply should not exist. This current behavior will ultimately result in
the build integration failing because "python_d.exe" is resolved, but it doesn't exist.

Interestingly, the property specified in versions 3.7.1 and earlier appear to define the correct path as:

<PythonHome>$(MSBuildThisFileDirectory)\..\..\tools</PythonHome>

My suggestion is to revert back to this older variant. If "python_d.exe" isn't needed, then it should be removed.
If it is needed, then the path needs to be fixed. To make the path more robust, I also recommend resolving this
path using one of the following forms:

<PythonHome>$([MSBuild]::NormalizePath($(MSBuildThisFileDirectory)\..\..\tools))</PythonHome>

OR

<PythonHome>$([System.IO.Path]::GetFullPath($(MSBuildThisFileDirectory)\..\..\tools))</PythonHome>


In my particular case, the tooling I'm plugging this into wasn't happy unless the path was absolute. There
doesn't appear to be any reason or downside to resolving the path ahead of time. I can easily workaround
that issue, but I suspect resolving an absolute path may be useful to other package consumers as well.

As soon as I know what the final form of the property should be, I'll submit the PR and update this issue with the link
History
Date User Action Args
2020-04-02 23:24:48sydefektsetrecipients: + sydefekt, paul.moore, tim.golden, eric.araujo, zach.ware, steve.dower, dstufft
2020-04-02 23:24:48sydefektsetmessageid: <1585869888.82.0.151743130482.issue40158@roundup.psfhosted.org>
2020-04-02 23:24:48sydefektlinkissue40158 messages
2020-04-02 23:24:48sydefektcreate