4 ms·

I'd like to jump in and endorse CMake, too, after spending some frustrated nights some years ago trying to add autogoo to a project. It was so mindblowingly ea

by Frondo 11y ago

I'd like to jump in and endorse CMake, too, after spending some frustrated nights some years ago trying to add autogoo to a project. It was so mindblowingly easy to get CMake to work--to detect/find paths for libraries, work on Linux and Windows, the whole nine yards--on a project I had, I had the basic cross-platform functionality up in a matter of hours on my very first attempt. And the makefiles it produces generate pretty colored output. :-) Autogoo knowledge seems like it's about on par with a deep knowledge of Xlib--good for anyone maintaining a legacy project, I'm sure.

jordigh 11y ago
> Linux and Windows, the whole nine yards That's the thing, if (a specific distribution of) Linux and Windows are all you care about, then CMake does the job just fine. Autotools solves the problem of being portable to every conceivable Unix, including many Unices people don't use anymore, and including Unixified Windows. Also, autotools solves the problem in a very specific way, test for features, not for versions: https://news.ycombinator.com/item?id=10752054 https://news.ycombinator.com/item?id=10752054
- GFK_of_xmaspast 11y ago
  > Autotools solves the problem of being portable to every conceivable Unix, including many Unices people don't use anymore, and including Unixified Windows. "Portable to ultrix and dg/ux" is not much of a selling point.
- Frondo 11y ago
  That sounds like what I said--portability to every conceivable unix, including ones that people no longer use--that autotools is good for legacy support. I'm trying to see what benefit there it to start a project in 2016 and wrestle with autotools, just so that you also gain access to unixes no one uses.
  - therein 11y ago
    Yeah, exactly. I don't think my C++11 code would be portable to ultirx and dg/ux anyway. :)
ploxiln 11y ago
CMake seems more difficult for the person building the software. I'm familiar with autoconf's configure options like --prefix and variables like CXXFLAGS, and if not I can see a reasonably short listing and explanation of them with `./configure --help`, and that list often includes other --enable-foo like options the project defined. CMake, on the other hand, does not (at least for the projects I've run into?) honor --prefix or CXXFLAGS as arguments to cmake, and cmake --help doesn't show what variables it does honor. Through googling and cargo-culting I've come up with some more cryptic replacements - `-DCMAKE_INSTALL_PREFIX:PATH=$PREFIX`, `-DCMAKE_CXX_FLAGS="-lrt"`. Now that I look at the `cmake --help` output again, I notice that in the middle of its long list of unhelpful output, there's mention of `--help-properties` and `--help-variables`, but the output is super long. Finally, I've seen indications that cmake is a huge pain if you want to add some custom targets and rules that it doesn't generate automatically for common languages in common layouts: https://samthursfield.wordpress.com/2015/11/21/cmake-dependencies-between-targets-and-files-and-custom-commands/ https://samthursfield.wordpress.com/2015/11/21/cmake-depende... I'm not a huge fan of autotools either, I tend to just write Makefiles directly (and not make any attempt at portability to Windows). It's actually not hard to correctly handle parallel, cross-platform, and cross-compiling support, just for linux / os x / bsd. It's a lot easier than fixing a cmake or autotools project that apparently messed something up in their configuration ...
- digi_owl 11y ago
  CMake do provide a UI of sorts for exploring the various options. You have to run cmake . once first to get the defaults generated, and then you can use ccmake . to get a UI. I find its insistence on all caps everywhere to be a bit of a annoyance though. But it guess it inherits that from make.
- jibsen 11y ago
  You might like this script that wraps cmake in a configure-like interface [1]. Also, CMAKE_INSTALL_PREFIX vs. --prefix is just different magical incantations. The obvious is sometimes what you are most used to. [1]: https://github.com/nemequ/configure-cmake https://github.com/nemequ/configure-cmake
JoshTriplett 11y ago
I've worked on projects using autotools, and worked on projects using CMake. While CMake does add Windows support without having to use MSYS or similar, I've found the syntax and language semantics of CMake incredibly painful to work with. CMake feels very "stringly typed", worse so than shell. For instance, the definition of if conditions: 'True if the constant is 1, ON, YES, TRUE, Y, or a non-zero number. False if the constant is 0, OFF, NO, FALSE, N, IGNORE, NOTFOUND, the empty string, or ends in the suffix -NOTFOUND. Named boolean constants are case-insensitive. If the argument is not one of these constants, it is treated as a variable.' CMake has variables, and something vaguely like dictionaries, but the syntax again seems very string-like, with a SET() function and the <name> PROPERTY <name> syntax. And on the flip side, CMake retains many of the quoting and argument splitting problems from shell scripting, without the well-established solutions for those. In general, CMake seems like an exercise in minimal syntax: "can we build a language with no operators or symbols?". The result feels wrong in the same way COBOL does. If you can treat CMake as a completely declarative language, it more or less works. However, the moment you have to actually use it as a programming language, it becomes painful. I'd rather have shell scripts than CMake, and that says a lot.
- gvalkov 11y ago
  I really liked the COBOL comparison. It's a real pity that nothing came out of their effort to use Lua[1] for the build language. [1]: https://cmake.org/pipermail/cmake/2007-November/017971.html https://cmake.org/pipermail/cmake/2007-November/017971.html

by Frondo 11y ago

jordigh 11y ago

> Linux and Windows, the whole nine yards That's the thing, if (a specific distribution of) Linux and Windows are all you care about, then CMake does the job just fine. Autotools solves the problem of being portable to every conceivable Unix, including many Unices people don't use anymore, and including Unixified Windows. Also, autotools solves the problem in a very specific way, test for features, not for versions: https://news.ycombinator.com/item?id=10752054 https://news.ycombinator.com/item?id=10752054

GFK_of_xmaspast 11y ago
> Autotools solves the problem of being portable to every conceivable Unix, including many Unices people don't use anymore, and including Unixified Windows. "Portable to ultrix and dg/ux" is not much of a selling point.
Frondo 11y ago
That sounds like what I said--portability to every conceivable unix, including ones that people no longer use--that autotools is good for legacy support. I'm trying to see what benefit there it to start a project in 2016 and wrestle with autotools, just so that you also gain access to unixes no one uses.
- therein 11y ago
  Yeah, exactly. I don't think my C++11 code would be portable to ultirx and dg/ux anyway. :)

ploxiln 11y ago

CMake seems more difficult for the person building the software. I'm familiar with autoconf's configure options like --prefix and variables like CXXFLAGS, and if not I can see a reasonably short listing and explanation of them with `./configure --help`, and that list often includes other --enable-foo like options the project defined. CMake, on the other hand, does not (at least for the projects I've run into?) honor --prefix or CXXFLAGS as arguments to cmake, and cmake --help doesn't show what variables it does honor. Through googling and cargo-culting I've come up with some more cryptic replacements - `-DCMAKE_INSTALL_PREFIX:PATH=$PREFIX`, `-DCMAKE_CXX_FLAGS="-lrt"`. Now that I look at the `cmake --help` output again, I notice that in the middle of its long list of unhelpful output, there's mention of `--help-properties` and `--help-variables`, but the output is super long. Finally, I've seen indications that cmake is a huge pain if you want to add some custom targets and rules that it doesn't generate automatically for common languages in common layouts: https://samthursfield.wordpress.com/2015/11/21/cmake-dependencies-between-targets-and-files-and-custom-commands/ https://samthursfield.wordpress.com/2015/11/21/cmake-depende... I'm not a huge fan of autotools either, I tend to just write Makefiles directly (and not make any attempt at portability to Windows). It's actually not hard to correctly handle parallel, cross-platform, and cross-compiling support, just for linux / os x / bsd. It's a lot easier than fixing a cmake or autotools project that apparently messed something up in their configuration ...

digi_owl 11y ago
CMake do provide a UI of sorts for exploring the various options. You have to run cmake . once first to get the defaults generated, and then you can use ccmake . to get a UI. I find its insistence on all caps everywhere to be a bit of a annoyance though. But it guess it inherits that from make.
jibsen 11y ago
You might like this script that wraps cmake in a configure-like interface [1]. Also, CMAKE_INSTALL_PREFIX vs. --prefix is just different magical incantations. The obvious is sometimes what you are most used to. [1]: https://github.com/nemequ/configure-cmake https://github.com/nemequ/configure-cmake

JoshTriplett 11y ago

I've worked on projects using autotools, and worked on projects using CMake. While CMake does add Windows support without having to use MSYS or similar, I've found the syntax and language semantics of CMake incredibly painful to work with. CMake feels very "stringly typed", worse so than shell. For instance, the definition of if conditions: 'True if the constant is 1, ON, YES, TRUE, Y, or a non-zero number. False if the constant is 0, OFF, NO, FALSE, N, IGNORE, NOTFOUND, the empty string, or ends in the suffix -NOTFOUND. Named boolean constants are case-insensitive. If the argument is not one of these constants, it is treated as a variable.' CMake has variables, and something vaguely like dictionaries, but the syntax again seems very string-like, with a SET() function and the <name> PROPERTY <name> syntax. And on the flip side, CMake retains many of the quoting and argument splitting problems from shell scripting, without the well-established solutions for those. In general, CMake seems like an exercise in minimal syntax: "can we build a language with no operators or symbols?". The result feels wrong in the same way COBOL does. If you can treat CMake as a completely declarative language, it more or less works. However, the moment you have to actually use it as a programming language, it becomes painful. I'd rather have shell scripts than CMake, and that says a lot.

gvalkov 11y ago
I really liked the COBOL comparison. It's a real pity that nothing came out of their effort to use Lua[1] for the build language. [1]: https://cmake.org/pipermail/cmake/2007-November/017971.html https://cmake.org/pipermail/cmake/2007-November/017971.html