[Python-ideas] Cmake as build system

[Ryan Gonzalez]

On May 27, 2015 4:20:10 AM CDT, anatoly techtonik <techtonik at gmail.com> wrote:
>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.

The main thing is that no API is perfectly cross-platform, and no API is bulletproof. Go can get away with that because Go is very opinionated. Python, on the other hand, has a huge user base that they don't want to tick off.

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.