[Python-ideas] Cmake as build system

[anatoly techtonik]

On Sat, May 23, 2015 at 2:48 AM, Ryan Gonzalez <rymg19 at gmail.com> wrote:
> HAHAHA!!
>
> Good luck! I've raised this issue before. Twice. Autotools sucks.

Yes. If even people from Linux world say that autotools suxx
( http://esr.ibiblio.org/?p=1877 ). Imagine frustration of someone with Windows
background. Perl, macros, what the hell is all this about?

> And makes
> cross-compiling a pain in the neck. Bottom line was:
>
> - C++ is a big dependency
> - The autotools build system has been tested already on lots and lots and
> lots of platforms

Orly? The ticket to build Python with MinGW on Windows was filled many
years ago, and I am not sure if it works. Maybe it was tested, but platforms
evolve and break things, so those Autotools probably contain more kludges
that it is realistic for maintenance.

> - Nobody has even implemented an alternative build system for Python 3 yet
> (python-cmake is only for Python 2)

Because Python development is concentrated around patching Python itself,
there is no practice in eating your own dogfood when making decisions. Take
a SCons, for example, and try to port that to Python 3. You will see the key
points that need to be solved (see the bulletproof unicode thread in this list).
If Python developers had those toys at hand, the Python 3 would be more
practical language, but looks like it is a task for a university or a
full time paid job, because it is not fun for anybody here to do actual
development *in Python*, and discussing Python usage issues in development
lists is discouraged even though the issues raised there are important for
language usability.

> - No one can agree on a best build system (for instance, I hate CMake!)

There is no best build system, because there is no build book with a
reference of "best" or even "good enough" criteria. Even Google failed to give
good rationale while releasing their Bazel. It sounded like "that worked for us
better". Also, most build packages are about a fairly complex subject of
tracking dependencies, caching and traversing graphs, and their documentation
often doesn't have any graphics at all! Knowing how long it takes for
a free time
coder to draw a picture, only the mighty company can allow that, but even they
don't allow their "valuable resources" to spend time on that.

So, the problem is not to use fancy build system, but to use one that most
people with Python background can use and enhance. CMake needs C++ skills
and a separate install, SCons can be stuffed into repository. I am sure there
are plenty of other Python build systems to choose from that work like this.
Also, if you look at why SCons codebase, you'll notice a huge wrapping layers
over subprocess management and other things that should came shipped with
the Python itself just to make it a good platform for system tools. I
believe that
the sole reason why Python loses to Go in systems programming is that the
complexity of those wrappings that you need to do over Python to make core
cross-platforms concepts right.

-- 
anatoly t.