3 ms·

The trouble is not supporting all the different Operating systems/compilers, as make can do that. The issue is when the OpenGL library location varies, even on

by padf 4y ago

The trouble is not supporting all the different Operating systems/compilers, as make can do that. The issue is when the OpenGL library location varies, even on the same OS/compiler set.

jchw 4y ago
It's kinda both. The problem is that it doesn't really make sense to do all of this work to configure the build directly in Make, so if you need any kind of expensive detection (like calling pkg-config or testing if some library function is available) it's best to do it in a configure script. Most projects don't have terribly special needs, so it would be both overkill (too much effort) and insufficient (not supporting enough use cases) to do a lot of custom configuration code. So most projects wind up using something like Autoconf, which has already done a ridiculous amount of work to work on almost everything, supporting important use cases like out-of-tree builds and cross-compilation, but even then it has some unfortunate limitations. As much as I don't think CMake is elegant or perfect by any means, CMake is nice because it does work, and there generally is a proper way to do things even if it's not always intuitive. And for how bad it can be, honestly, it's much less of a pain in my opinion than dealing with autotools, for many reasons. Just to be concrete about it, one thing I find really painful with autotools is trying to find the exact combination of versions that will actually work with a given project... With CMake, usually newer versions are always OK, and there's a decent focus on both backwards compatibility as well as explicitly declaring the required CMake version. There's more, but it's probably not worth getting into, as I don't think most people defend autotools as being particularly nice to use. Some projects, like the Linux kernel, can definitely get away with Make and custom configuration, since a lot of higher-level general purpose tools are not really well-suited for their needs anyways. I feel like most projects (somewhere on the order of >99% of them) are not really in this boat.

by padf 4y ago

The trouble is not supporting all the different Operating systems/compilers, as make can do that. The issue is when the OpenGL library location varies, even on the same OS/compiler set.

jchw 4y ago

It's kinda both. The problem is that it doesn't really make sense to do all of this work to configure the build directly in Make, so if you need any kind of expensive detection (like calling pkg-config or testing if some library function is available) it's best to do it in a configure script. Most projects don't have terribly special needs, so it would be both overkill (too much effort) and insufficient (not supporting enough use cases) to do a lot of custom configuration code. So most projects wind up using something like Autoconf, which has already done a ridiculous amount of work to work on almost everything, supporting important use cases like out-of-tree builds and cross-compilation, but even then it has some unfortunate limitations. As much as I don't think CMake is elegant or perfect by any means, CMake is nice because it does work, and there generally is a proper way to do things even if it's not always intuitive. And for how bad it can be, honestly, it's much less of a pain in my opinion than dealing with autotools, for many reasons. Just to be concrete about it, one thing I find really painful with autotools is trying to find the exact combination of versions that will actually work with a given project... With CMake, usually newer versions are always OK, and there's a decent focus on both backwards compatibility as well as explicitly declaring the required CMake version. There's more, but it's probably not worth getting into, as I don't think most people defend autotools as being particularly nice to use. Some projects, like the Linux kernel, can definitely get away with Make and custom configuration, since a lot of higher-level general purpose tools are not really well-suited for their needs anyways. I feel like most projects (somewhere on the order of >99% of them) are not really in this boat.