On May 27, 2015 4:20:10 AM CDT, anatoly techtonik
On Sat, May 23, 2015 at 2:48 AM, Ryan Gonzalez
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.