cmake: migration guide/ cheat sheet for make users

2018-06-11 02:18:27

I'm looking at replacing a configure/make style build process with cmake. cmake performs well on the complicated stuff but is more verbose on simple things. For instance the GNU Make file:

hello:
    echo "hello world" >$@

In cmake would be:

add_custom_command(OUTPUT hello
  COMMAND echo "hello world" > hello)
add_custom_target(all ALL DEPENDS hello)

See also adding a custom command with the file name as a target

which is actually more like:

hello:
    echo "hello world" >hello

all: hello

With more complex builds the absence of automatic variables (http://www.gnu.org/software/make/manual/html_node/Automatic-Variables.html) is very noticable.

After much routing around (it seems to be hard to search for $@) I found:

Automatic variables in CMake

which suggests using wrapper functions and

Path to target output file

which suggests using generator expressions that are close to automatic variables but not close enough.

I have several related questions:

1a) Has cmake itself or best practice for doing this moved on since that question was asked?

1b) Is it likely cmake will ever provide an equivalent to automatic variables? If not why not?

Individual problems are quite well covered on stackoverflow and elsewhere on the net but:

2a) Are there any good guides or cheat sheets to help with migrating from using GNU make directly.

2b) Are they any good best practice guides for cmake?

That is beyond the suggestions in 'Makefile equivalent in CMake'. I am gradually evolving my own style but would like to avoid horseless carriage type mistakes and needless complexity.

This is hard to answer, because CMake is not equivalent to make. It's much easier to compare CMake to autotools, for example, because it is a build system generator rather than a build system by itself.

Regardless, let's try to provide some answers.

1a+b) No, because it is not in the scope and philosophy of CMake to provide such constructs.
CMake's syntax is usually more on the side of verbosity, with explicit variable names such as ${CMAKE_CURRENT_SOURCE_DIR} as well as named command parameters. It looks more like a "classical" imperative programming language rather than a specialized textual description of a dependancy graph which Makefiles are.
Also, CMake's output can be Makefiles or pretty much anything else, so a certain level of abstraction is needed.

The best practice in your case would be to use macros:

macro(build_echo_foo ${target})
    add_custom_command(OUTPUT ${target}
        COMMAND echo "hello world" > ${target})
    add_custom_target(${target}_target ALL DEPENDS ${target})
endmacro()

build_echo_foo(hello)
build_echo_foo(another_hello)

Where Makefiles encourage the author to be as generic as possible, to minimize typing, CMake tries to make things as unambiguous as possible, for example by encouraging the maintainer to explicitely list source files instead of providing wildcards.

2a+b) Answering this is not exactly in the scope of Stackoverflow, but I'll say this. The best source of inspiration is open-source projects using this system. As of 2014, there are a good number of high-profile projects that have migrated to CMake. You can even study CMake's own source code, which uses itself as build system.

链接地址: http://www.djcxy.com/p/31878.html

上一篇: 可执行目标名称被保留