[python3] Build interpreter #14891
[python3] Build interpreter #14891
Conversation
Hoikas
force-pushed
the
py3_interpreter
branch
3 times, most recently
from
41a5962 to
5bbbc8e
Compare
This allows overriding the name of the install target, allowing specification of something other than `make install`, eg `make altinstall`.
Hoikas
force-pushed
the
py3_interpreter
branch
from
5bbbc8e to
b92662f
Compare
JackBoosY
added
category:port-feature
Hoikas
force-pushed
the
py3_interpreter
branch
from
b92662f to
af9a642
Compare
JackBoosY
added
the
depends:different-pr
|
I should have mentioned a few days ago... This is ready for review now that the baseline issues have been fixed. |
|
Oh sorry, I forgot this PR. |
|
/azp run |
JackBoosY
removed
the
depends:different-pr
|
Azure Pipelines successfully started running 1 pipeline(s). |
JackBoosY
added
requires:author-response
info:reviewed
|
After re-reading the previous messages, it seems like there is a quite a bit of work to do to properly "fix" every issue with static Python. All of which is outside the scope of this pull request, which is to simply build the interpreter itself. So, I restored the original static CRT functionality. The interpreter built with a static CRT works in my testing, so I think that should address @ras0219-msft's concern in that python3 will not cause any cascading skips on the x64-windows-static triplet. Note that the original patch for static CRT support is now handled by a props file. |
|
It looks like the macOS builder died before it even got started. Could someone kindly trigger a rebuild on this? 😅 |
It says passed to me? |
|
Heh, I swear when I originally posted that, AZP had "stopped hearing from" the macOS machine. Maybe that wasn't a hallucination 😄 |
In microsoft#14891 @Hoikas points out that the port depends on Python but the portfile.cmake explicitly disables it with `-DPYILMBASE_ENABLE=FALSE`.
|
It looks like hyperscan was already fixed. |
|
I restarted the pipeline test and the regression is gone. |
|
Thanks for your contribution! |
In microsoft#14891 @Hoikas points out that the port depends on Python but the portfile.cmake explicitly disables it with `-DPYILMBASE_ENABLE=FALSE`.
In microsoft/vcpkg#14891 @Hoikas points out that the port depends on Python but the portfile.cmake explicitly disables it with `-DPYILMBASE_ENABLE=FALSE`.
This change allows the python3 port to install the interpreter as a tool. This is useful because, when embedding python3 in a program, the python standard library must be available in the final application (read: bundled). CMake provides the location to the standard library on the build machine, but the interpreter itself is required for this functionality to work. More critically, CMake 3.12+'s python find modules require that the python executable and development libraries match exactly, or it will either reject the supplied (read: vcpkg) libraries and either fail or silently use the system libraries, causing an undocumented gotcha dependency on the system python's
major.minorversion matching vcpkg's exactly.Internally, this changeset removes the usage of custom calls to
configureandmakeon unix-like platforms and replaces them with vcpkg'svcpkg_configure_makeandvcpkg_install_make. This was extracted from #13556 and represents the minimal "first half" of said extraction. The second half of the extraction will be thevcpkg-cmake-wrapper, which will further improve the story around consumers of the python3 port.What does your PR fix?
Fixes [python3] Install python executable from port #10903
First half for [python3] cmake FindPython3 Development component #9026
Which triplets are supported/not supported? Have you updated the CI baseline?
Static CRT support has been removed, so x64-windows-static support has been dropped. Previously, the python3 port would perform trickery around the static CRT. Static CRT support does not make sense in python3 due to its extension model. The community triplets x86-windows-static-md and x64-windows-static-md are unaffected by this change.
Does your PR follow the maintainer guide?
Yes