Thanks for raising the question.

So far, maintaining the build system for multiple version of Python in one single location has been practical.

I wonder what the other contributor think ?

Cc: @python-cmake-buildsystem/team-python-cmake-buildsystem @ihnorton

I agree the patches might be simpler to keep track of, and it would then be possible to make "release" tarballs if needed. I guess merging the CMake code into the tree would slightly simplify builds (one stage instead of two), but not sure it's worth confusing the commit history.

Moreover it will be easier to propose a replacement for the current build system.

Upstream is not going to introduce a new build system in the 2.7 branch.
My suspicion is the probability they would consider CMake for 3.7/8... is very close to 0, but I guess it's not impossible.

+1 for creating a branch from python/cpython. This would be nicer for application of patches. But, more importantly, as @cav71 pointed out, it would really help pave the way for integration upstream.

Thanks for the feedback 👍

At some point, I think it will make sense to merge the build system. Ideally, it should be fully integrated and maintained in the upstream project.

Considering that we are currently supporting python 2.7.x and python 3.x, I would prefer we keep the build system in its own project. It makes the overall maintenance easier. After Slicer project transitions to python 3.x, creating a branch of python/cpython would also make more sense. Indeed, one of the original project driving the maintenance of the build system is the integration of python within Slicer.

In the mean time, I suggest we update the minimum version of CMake, it was already discussed back in 2016 but we didn't act on it. See #116 Similarly to ITK, may we be we could pick CMake 3.9.5. This would leverage "modern" CMake constructs.

As an experiment and to test the waters, may be we could create a branch of upstream project and (re-)start discussion for integration ? @cav71 would you like to take the lead on that ? This could be done now or after we update the version of CMake.

To provide some more context:

• Here was an attempt by @neundorf to introduce a CMake based build system to the cpython community: http://grokbase.com/p/python/python-dev/0948wgpp46/evaluated-cmake-as-an-autoconf-replacement
• This project (python-cmake-buildsystem) is based on the initial work for @davidsansome (see Add @jcfr as project maintainer #6) and @neundorf @patmarion and @demarle (see 9baa8f2) with contributions from many more 👍

Here's a bit more context when the idea was brought up before; one big objection is the C++ dependency:

• https://mail.python.org/pipermail/python-ideas/2015-March/032381.html
• https://mail.python.org/pipermail/python-ideas/2015-May/033644.html

@cav71 if you wanted to push this, the way to do it is first to bring it up again on python-ideas, and if there is sufficient buy-in, then write a PEP.

@jcfr testing waters here... I've forked cpython and created a cmake branch at:

https://github.com/cav71/cpython 

It is an initial proof-of-concept and it contains three distinct change sets:

• core changes (eg. the one requiring upstream collaboration/approval)
  cav71/cpython@4f36341

• cmake documentation changes (contained under Doc/cmake)
  cav71/cpython@198d822

• cmake changes for the build system (eg. CMakeList.txt and director cmake)
  cav71/cpython@52f14af

The core changes are kept at bare minimum and hopefully they won't need any upstream effort.

The cmake doc is self contained inside a folder so. I've added a make.py but is not required as the standard make.bat will work as well.

The cmake based build system it is also self contained, maintenance here will be just copying files.

I think this will require the minimum maintenance possible from both upstream and downstream.

@ihnorton that self contained layout will allow to filter easily the history. Also if the direction is good we can test waters with python-ideas with something a bit more concrete, if we'll get python core traction we can start a PEP.

During the CI testing of this project (python-cmake-buildsystem) I assume that patches are applied to each supported version of python to verify that the patch applies cleanly? Perhaps during that automated test the patched results could be force pushed to a cpython repo fork. The cpython fork could have a branch for each supported python version. This fork could be a convenient repo for folks to clone from, for their convenience, rather than having to apply the patches themselves.

I assume that patches are applied to each supported version of python to verify that the patch applies cleanly?

Yes. This is currently done by the build-system using cmake/PythonApplyPatches.cmake module. Application of the patches is not specific to the CI.

Application of the patches can also be controlled disabling the option PYTHON_APPLY_PATCHES

Perhaps during that automated test the patched results could be force pushed to a cpython repo fork.
The cpython fork could have a branch for each supported python version. This fork could be a
convenient repo for folks to clone from, for their convenience, rather than having to apply the patches > themselves.

For convenience, the patch are currently maintained in a fork.

See https://github.com/python-cmake-buildsystem/cpython

@cav71

The cmake based build system it is also self contained, maintenance here will be just copying files.

This approach would indeed streamline the maintenance on our side.

test waters with python-ideas with something a bit more concrete, if we'll get python core traction we can start a PEP.

👍

May be you could create a Google doc where we would draft the email to send to the python-idea mailing list ?

Also here is a poster we submitted back in 2014 to SciPy conference, there is probably some text in the abstract that could be reused.

Here's the proposal:
https://docs.google.com/document/d/1PGFd2tyd3e08dsstg0qSJoBX3oDvLTFNGV4zF61taYs/edit?usp=sharing

Here's the proposal:

This is great. Thanks for moving this forward 👍

I just suggested few changes.

I've merged the changes, thanks. How do I share the edit permissions in google?
I've also added a "build" matrix hopefully to gather information about the build targets https://docs.google.com/spreadsheets/d/1YMTkNxhtz90oLMHJBTpJjd4SS5tohI4lDCounWqVNFc/edit?usp=sharing

Looks great!

Should we have a FAQ section that preempts some possible mis-informed objections, e.g. that it requires C++?

e.g. that it requires C++?

Has CMake been ported to C?

Has CMake been ported to C?

No, CMake has not been ported to C. The point is ... that is missing the point. ;-)

What should be a concern:

1. Is CMake available on all targeted systems?
2. Will CPython require a C++ compiler to build?

The answers are yes and no, respectively. CMake is available on all systems with a minimal C++ compiler, from embedded systems to supercomputers. You do not need a C++ compiler to build a C project configured with CMake.

If I understand correct the key points are:

1. cmake is itself a standalone binary (eg. no need to build cmake itself to use it)
2. it doesn't require superuser permissions to use it

no. 1 is important because it will require an extra effort on the developers, no. 2 is important because not always users have those permissions (eg. in a corporate world that's very common).

I'll put a note in the main document,
Thanks

PS.

Should we have a FAQ section that preempts some possible mis-informed objections, e.g. that it requires C++?

I've placed a document under https://docs.google.com/document/d/1PGFd2tyd3e08dsstg0qSJoBX3oDvLTFNGV4zF61taYs/edit?usp=sharing

cmake is itself a standalone binary (eg. no need to build cmake itself to use it)

This is definitively true on all platform targeted by the official python distribution

it doesn't require superuser permissions to use it
yes

Closing.

CPython patches specific to python-cmake-buildsystem are maintained here:

https://github.com/python-cmake-buildsystem/cpython#readme