[scrollaway]

CMake is a million times better than autotools and respects prefix-setting, cross compiling etc in standard ways as well. Uniformity is not unique to autotools.

CPython extension building, however, sucks. setup.py is a bit of an abomination... It's really every language decides to reinvent the wheel for their own language. By now we could've had standards, and standard software, for package distribution and installation instead of having pip, go get, npm and a thousand others.

[dmm]

cmake is very nice. I used it in my last big c++ project. The cmake language is ugly but I think it's a law or something that build tools use ugly languages.

One advantage of autotools is that it distributes everything as a portable shell script, so the user doesn't have to have a autoconf, etc installed. That was an advantage when giving tarballs to users to run on crazy cluster environments, for example. Anything that calls itself unix has to have a bourne shell. Oh well probably not that big of an advantage these days.

I was really complaining more about dunno-works-on-ubuntu GNUMakefiles and 90s scripting languages extention builds.

[scrollaway]

I agree, the CMake language is needlessly different and ugly. But it's readable and usable which matters a lot more.

I heard there's movement inside the CMake community to move to lua as a language, which would be awesome.

[antonyme]

CMake actually does platform probing (test compiling with code fragments to identify platform features and quirks) in a similar manner to autotools. But it is much easier to work with, and significantly better documented. I find the syntax shouty and verbose but it does the job, and has proven its mettle in many large, complex cross-platform projects.

As for CPython extensions, I can relate also. Though the cffi makes some of it redundant, and Boost::Python is brilliant for wrapping C++ projects.

[striking]

Is there a way other languages could fit into an established build framework like CMake?

Or is this a "bigger problem" that no one has really tackled yet?

[scrollaway]

It's a "bigger problem". New languages bring new build systems and there really isn't much you can do about that.

However, what could be standardized is package distribution. I shouldn't have to have 10 different package managers for 10 different languages, each of them with different ways of expressing essentially the same metadata, etc.

As a language developer, I shouldn't be expected to create my own version of a package manager, with download, local / remote search, versioning, vcs support, upgrades, hooks, and a million other things. Package managers are complex beasts.

It's a bit like if every javascript project was expected to create its own http server. Except it's not http, it's a weird custom protocol they invented just for the sake of it. Naaaaasty.

[striking]

Arch Linux's "pacman" is exactly what you're looking for in those regards (to some degree). The only problem is that using pacman repositories instead of the language builtin ones means you're going to have issues with global installation and so on and so forth.

But you raise some really good points. I have to ponder this further.

[scrollaway]

Of course! pacman is one of the best package managers out there (and the best I've personally used). But its developers sadly don't share in the vision of using pacman outside Arch Linux. It's a wonder it works on msys2.

It's a point I tried to raise in the past but without much success. If you want to start a project to fix this, email me (especially if it's centered around pacman - I'm an arch TU).