Slashdot Mirror

Multiple companies work by providing free software, advertise that they produce it, provide services for it, etc. For example, cmake is produced, supported, and advertised by Kitware (see: https://cmake.org/). It's great advertising for them. (Note, I am not associated with Kitware, but I know some of the developers.)

There is a possible a business model for a company to create the software that the person wants and release it for free and use that to advertise their services. And there is a distinct possibility that the person has come up with an idea that the company has not and would be interested in. So, how would that person make the idea known to companies looking for ideas?

You can think of CMake as autoheader, autoconf, automake and libtool rolled up into one tool. It's a scripting language which is evaluated, the end products being generated files of any type you like, plus the files for a specified build system, typically Makefiles on UNIX, but could be many other types. It's a superset of the functionality of the autotools, and is vastly more maintainable and flexible, not to mention portable to non-POSIX platforms. It's not the nicest language I've encountered, but it's certainly better than the multi-language mess of m4/shell/templates we live with in the Autoconf world.

You can do all the feature testing with CMake that you can with Autoconf. For example, in place of AC_TRY_COMPILE, you use CHECK_C_SOURCE_COMPILES, or the equivalent in another language. There are variants for all sorts of other feature tests and checks, same as with Autoconf. But in general, I think it solves current portability problems somewhat better and more portably that the Autotools, which seem to still be stuck in the 90s in terms of the problems they try to solve. Example: portably enabling threading.

When creating custom headers for macros from the feature test results, in place of AC_CONFIG_HEADER you would use configure_file, which does exactly the same thing using CMake variables.

After 15 years of autotools usage, I converted my most important projects to CMake around 22 months ago, and haven't looked back. Most recently, I did conversions from autotools for bzip2 and libtiff. In both cases, the conversion is pretty much a 1:1 change from Autoconf macro or Automake variable to the corresponding CMake macro/function/variable.

Regards,
Roger

You can think of CMake as autoheader, autoconf, automake and libtool rolled up into one tool. It's a scripting language which is evaluated, the end products being generated files of any type you like, plus the files for a specified build system, typically Makefiles on UNIX, but could be many other types. It's a superset of the functionality of the autotools, and is vastly more maintainable and flexible, not to mention portable to non-POSIX platforms. It's not the nicest language I've encountered, but it's certainly better than the multi-language mess of m4/shell/templates we live with in the Autoconf world.

You can do all the feature testing with CMake that you can with Autoconf. For example, in place of AC_TRY_COMPILE, you use CHECK_C_SOURCE_COMPILES, or the equivalent in another language. There are variants for all sorts of other feature tests and checks, same as with Autoconf. But in general, I think it solves current portability problems somewhat better and more portably that the Autotools, which seem to still be stuck in the 90s in terms of the problems they try to solve. Example: portably enabling threading.

When creating custom headers for macros from the feature test results, in place of AC_CONFIG_HEADER you would use configure_file, which does exactly the same thing using CMake variables.

After 15 years of autotools usage, I converted my most important projects to CMake around 22 months ago, and haven't looked back. Most recently, I did conversions from autotools for bzip2 and libtiff. In both cases, the conversion is pretty much a 1:1 change from Autoconf macro or Automake variable to the corresponding CMake macro/function/variable.

Regards,
Roger

Huh? Do you even know what CMake is? Please stop embarrassing yourself.

These days I spend more time ./configuring than I do actually compiling, especially with distcc (./configure not being parallelizable)

That's a fair criticism. I'm sure that large parts of ./configure could be parallellized; however, they're shell scripts for maximum portability, and shell scripts are not parallel. Maybe someone could write a python-generator for autofoo, which would then be rejected by upstream because they can't guarantee that every Unix(y) system has python available.

Even worse, sometimes I need to rebuild all of the scripts due to some patch, and that adds even more time to an already ridiculously inefficient process.

Have you heard of --config-cache ?

why do I need to check for a C compiler, determine the maximum length of commandline arguments, and figure out if I have 20 system headers and 30 libc functions

You don't. But the package under compilation wants to know, or it wouldn't have included the check. And if you want to avoid it, you can easily write a config.cache file by hand, so you don't have to wait for configure to find it out. Autoconf macro variable names are consistent, you know.

every time I want to compile a package?

You don't. You want to determine it once per package, per host

Meanwhile, CMake is a hell of a lot faster, uses a more modern language, and can integrate better with other build environments. I've used CMake for a couple of projects and, although the language does have its quirks, it's mostly been smooth sailing. Where I don't use/need CMake, I use simple Makefiles.

So do I. Have you ever tried to crosscompile, though? Say, targeting a *BSD system from your Linux machine? Ever wrote portable code, that works for more than just your current machine? That must work on machines you've never even heard of?

So no, I'm not in a position of familiarity with both systems to be able to do a detailed objective comparison as a developer, but as a user I can clearly say CMake is much superior (at least the way it is used by actual projects)

You mean, as a non cross-compiling user. For reference, compare the cross-build procedures for an Autotools build versus a simple Makefile. Now, I've never used CMake for cross-compiling, but it doesn't seem particularly easier than autotools. And as a user, I very much appreciate the default arguments to configure: --help, --prefix, --enable-*, --with-* . Also default out-of-tree building, DESTDIR support and uniform targets (check, install, dist, distclean) make packaging such software a breeze.

and as a developer I can at least say CMake is nice. Several large projects have migrated from autotools to CMake, and I bet they had a good reason.

My biggest beef with autofoo has been the apparent incompatibility between versions: it seems that every other version, there are macro's deprecated or slightly modified, I once had a problem where an upstream project would only build with autoconf X, but it depended on gettext Y, and gettext required that I install autoconf X+2

Obligatory link to a good autotools alternative: CMake. And my CMake tutorial, Learning CMake.

Have you tried to define CMAKE_INSTALL_PREFIX, CMAKE_INSTALL_RPATH / CMAKE_SKIP_RPATH, etc when configuring the software you are trying to build? I'd say they pretty much fix whatever problems you are running into. BTW, CMake also supports "make install DESTDIR=/whatever"

Have you tried to define CMAKE_INSTALL_PREFIX, CMAKE_INSTALL_RPATH / CMAKE_SKIP_RPATH, etc when configuring the software you are trying to build? I'd say they pretty much fix whatever problems you are running into. BTW, CMake also supports "make install DESTDIR=/whatever"

Have you tried to define CMAKE_INSTALL_PREFIX, CMAKE_INSTALL_RPATH / CMAKE_SKIP_RPATH, etc when configuring the software you are trying to build? I'd say they pretty much fix whatever problems you are running into. BTW, CMake also supports "make install DESTDIR=/whatever"

Here you go.

i agree with the parent's other points but i strongly disagree with this one:

Use autoconf to handle platform idiosyncrasies.

autoconf is gross and difficult to use on Windows.

i use CMake at work and like it well enough. it works well enough with Qt that KDE uses it for their build system.

For a real nice cross-platform build system with more of a C++ bias, check out CMake + Dart. I've recently been forced into developing on a Windows desktop rather than Linux. I've got everything running smoothly under cygwin, including nmake VC++ (one of CMake's targets) builds from within emacs.

There's no "pure" version of GCC for Windows is because there's no demand for anyone to build one. The only reason you'd want to would be if you had some fundamental objection to Cygwin.

I'm really glad to see CMake finally getting used by a high-profile project. I hated CMake at first sight -- having to install it first before I could build a project seemed strange after the autoconf ./configure; make routine. But it really is a nice system and has meant no longer having to support and keep in sync parallel make files, Visual Studio projects, XCode projects, etc. like I used to. Configure scripts failing on native Windows builds, for example, was always a pain. It's been a lot easier to build cross-platform projects now that I'm using CMake for everything.

Seeing KDE adopting it has been great news for me, since it means that I may be able to start releasing my own small projects with CMakeList.txt files without getting funny looks. I love that it's looking like KDE will blaze the trail for us little guys who prefer CMake over the autoconf tool chain.

I find CMake tremendously useful, as it lets me manage most of my configuration in a cross-platform manner. I can transparently take the project over to Windows to build with NMake or Visual Studio. I don't use the XCode support very much, as the Makefiles generated by CMake seem to work pretty well.

VTK has also spawned off two other opensource projects, DART and Cmake.

All these tools (and also cmake and A-A-P mentioned in the other reply) are great for developers but not ideal for the end user who almost surely doesn't have them installed on his machine.

If you want to use something as easy on developer but which would still require no additional on the users machine, have a look at bakefile. This is a very useful tool, especially for open source programs where users often have or are asked to rebuild the program from source and installing additional tools is just an extra hurdle for them.

If you are also considering hacing at least part of the code work on both Windows and UNIX, having CVS or Subresion for source control and Scons or CMake for build control might help. Where I work we develop on windows, Linux and Solaris and we are using CVS & scons (scons/python seemed better than learning to use the cmake scripting language).

My Anonymous Friend... The salutations are appreciated. It has been a challenge for our team to develop and to share the GPSTk. I hope you discover its benefits, and I hope they outweigh the distastefulness of Perforce and Jam.

Please allow me to briefly explain why Jam was deliberately chosen over the GNU autoconf toolchain as the build process for GPSTk.

Jam addresses a larger set of users than GNU autoconf. Does configure work using the Borland free compiler? With MS .NET or MSVCC? No. We did not want to ignore that important community, not did we desire to support multiple build processes. Can make resolve library dependencies dynamically (upon invocation)? No. These are practical examples of why Jam was chosen over the autoconf/configure/make toolchain for the GPSTk.

Jam is not just a "hack" as one reply claims but a serious contender for the replacement for the make/configure/autoconf toolchain. If autoconf/make is such the obvious choice for all projects--then why are there so many alternatives? Other make variations or replacements include ant, cmake, qmake, and confix.

However I will be the first to admit Jam has flaws. Poor documentation is perhaps the greatest. Lack of familiarity is a runner up IMHO. Despite its flaws, Jam was chosen for its simplicity.

Perhaps the above sounds too defensive. I don't want to make the impression that the GPS Toolkit team would not consider switching to, say, CMake or autoconf. We have chosen the Open Source route for this project. The "many eyes" principle is founded upon challenge--we should accept this challenge to our build process. And we know we are asking for challenge by not following the autoconf convention. But the effort to switch build processes would only be considered if (1) the new build process broadened the user base or (2) it addressed technical inability in the current build process. Otherwise, the choice of build tool is arbitrary and if so, our choice is Jam.

• cmake
  
• scons
  

As a user, I give up when dealing with unpleasant configure errors.

As far as makefiles go, cmake looks promising. It seems to be a generalized Imake replacement. I haven't used it, but looks interesting. It is now part of the cygwin toolchain.

as far as tools go, look at cygwin. My company uses gnumakefiles on NT and UNIX, with generalized Makefiles for each project, and platform specific build rules in universal gmake include heeaders. We use ACE for a lot of the cross platform C++ stuff, a lot of our things are servers so we avoid the cross platform GUI stuff.