| |||||||||||||
Kamp: A Generation Lost in the BazaarKamp: A Generation Lost in the BazaarPosted Aug 22, 2012 18:27 UTC (Wed) by cmccabe (guest, #60281)In reply to: Kamp: A Generation Lost in the Bazaar by nix Parent article: Kamp: A Generation Lost in the Bazaar
> However, I note that makefiles are themselves little more than
> dependencies tied to shell script fragments, so clearly the shell and make > are relatively tightly associated (indeed, make knows internally what > characters are common shell metacharacters, and stuff like that).
Again, this is not a binary choice between plain old Makefiles and autotools. My choice is CMake.
CMake has its own scripting language which is portable across platforms (including Windows), versioned, and specifically designed for this use-case. Using the policy mechanism you can tell CMake "act as if you were CMake 2.6." Anyone with a version of CMake higher than or equal to 2.6 can then compile your project exactly as you intended. Shell scripts don't have any of these things.
Yes, shell scripts are appropriate for some use cases. But a build system is just not one of them. Let's use the right tool for the job rather than trying to explain how with a little duct tape, a plunger can be used as a hairbrush.
At the end of the day, nothing can make your code portable but you. But the build system can help you or hurt you. If it closes off platforms to you, like autotools closes off Windows to you, that hurts. If it forces you to write shell scripts to do everything, that hurts portability too. I've spent a long time fixing build breakages that resulted from autotools' poor choices. The question of what kind of Makefile.am or configure.ac a superintelligent Zen master who has studied AIX, IRIX, csh, tcsh, bash, zsh, dash, and every other shell out there might write is not interesting to me. In the real world, autotools = not portable.
(Log in to post comments)
Kamp: A Generation Lost in the Bazaar Posted Aug 22, 2012 19:21 UTC (Wed) by hummassa (subscriber, #307) [Link]
That is really not my experience. I prefer CMake to autotools for new code, but CMake was not really crosscompiler-friendly the last time I checked. Autotools is really much more complicated, but it will even work in MinGW/CygWin without a lot of problems... and it will suport crosscompiling without a lot of EXTRA effort. Yes, it is possible that CMake works well with MSVC, but I wouldn't know about it.
Kamp: A Generation Lost in the Bazaar Posted Aug 22, 2012 20:17 UTC (Wed) by boudewijn (subscriber, #14185) [Link]
I know that it does work well with msvc. I also know that it works well when cross-compiling from linux to windows. Maybe the setup is a bit more involved than with autotools, maybe it's not -- maybe the people feel it is more involved just don't remember the effort they expended on the autotools setup when they had to work with it for the first time. And yes, cmake works very well with mingw on windows itself.
Really, people who have an opinion on cmake and autotools in relation to windows, whether it's with mingw, msvc, or icc, but haven't checked out the way the kde-windows project uses cmake should check it out. Doing that will make their life _much_ easier.
Kamp: A Generation Lost in the Bazaar Posted Aug 24, 2012 1:16 UTC (Fri) by cmccabe (guest, #60281) [Link]
CMake has supported cross-compiling for a long time. http://www.vtk.org/Wiki/CMake_Cross_Compiling
Various projects may have trouble with cross-compiling, because their authors did something problematic (like assuming that they could build a binary with the target compiler and then run it, or using hard-coded paths in a dumb way). However, this is just as true with autotools. Fix the bugs and move on.
|
|||||||||||||