如何在 Cmake 构建系统中使用目录中的所有 * . c 文件？

我想找到一切。并将它们全部添加到要在 cmake 中编译的 SRC 文件中。我如何在 CMakeList.txt 中实现这一点。

我可以创建的常规 makefile

SPECIFIED_SRC_FILE  = $(foreach d,$(SPECIFIED_SRC_DIRS),$(wildcard $(addprefix $(d)/*,*.c)))

但是我无法在 CMakeList.txt 中执行这样的操作。

109268 次浏览
小开
最佳答案

Try this:

AUX_SOURCE_DIRECTORY

Find all source files in a directory. 

AUX_SOURCE_DIRECTORY(dir VARIABLE)

Collects the names of all the source files in the specified directory and stores the list in the variable provided. This command is intended to be used by projects that use explicit template instantiation. Template instantiation files can be stored in a "Templates" subdirectory and collected automatically using this command to avoid manually listing all instantiations.

It is tempting to use this command to avoid writing the list of source files for a library or executable target. While this seems to work, there is no way for CMake to generate a build system that knows when a new source file has been added. Normally the generated build system knows when it needs to rerun CMake because the CMakeLists.txt file is modified to add a new source. When the source is just added to the directory without modifying this file, one would have to manually rerun CMake to generate a build system incorporating the new file.

小开

You can use AUX_SOURCE_DIRECTORY as @whitequark described, but it won't really work as you expect, as CMake will be unable to determine when new files are added (which is kind of the whole point with using a wildcard).

小开

How about the good old globbing?

FILE(GLOB MyCSources *.c)
ADD_EXECUTABLE(MyExecutable ${MyCSources})
小开

Yes, you have two options. Let's assume you the folder structure something similar to this. 

├── autopilot
│   ├── _AutoPilot.cpp
│   ├── _AutoPilot.h
│   └── action
│       ├── ActionBase.cpp
│       ├── ActionBase.h
│       ├── APcopter
│       │   ├── APcopter_avoid.cpp
│       │   ├── APcopter_avoid.h

If you are to use AUX_SOURCE_DIRECTORY you have to add CMakeLists.txt each one of sub directories. Then you have to include and link all those subdirectories. This is quite a difficult task. So you can you GLOB and do the job very easily. This is how it is done.

  file(GLOB autopilot_sources ./**.cpp ./**.c)
SET( autopilot ${autopilot_sources})

If you want to create a library using above source code this is the command: 

  ADD_LIBRARY ( autopilot  ${autopilot_sources})
TARGET_LINK_LIBRARIES ( autopilot)

If you want to create an executable file using above source code this is the command: 

 ADD_EXECUTABLE(autopilot ${autopilot_sources})
小开

GLOB_RECURSE recursive example

It basically makes the * also go into subdirectories:

cmake_minimum_required(VERSION 3.0)
file(GLOB_RECURSE SOURCES RELATIVE ${CMAKE_SOURCE_DIR} "src/*.c")
add_executable(main ${SOURCES})

And then our sources could be located for example as:

src/main.c
src/d/a.c
src/d/a.h

And main.c uses #include "d/a.h" and a.c uses #include "a.h".

Using GLOB_RECURSE on the CMake toplevel (i.e. "*.c" instead of "src/*.c") is likely a bad idea, as it can pick up .c files generated by CMake itself which are placed under build/.

Runnable example on GitHub.

小开

The only correct answer is to not do this. This has been detailed in multiple answers here on SO. I will summarize here, in decreasing order of importance.

  1. The developers have explicitly stated1 that it is wrong to do this. That should give you pause. If you encounter an issue, the developers will likely not be receptive to fixing it for you, but will rather tell you to list your sources.
  2. The aux_source_directory function is outright incorrect since it cannot detect changes in the filesystem. For the same reason, using file(GLOB or file(GLOB_RECURSE without CONFIGURE_DEPENDS is outright incorrect.
  3. CONFIGURE_DEPENDS is not guaranteed to work. (See point 1)
    1. In fact, it was buggy on Windows before Ninja 1.10.2.
    2. It also breaks dry-run workflows since the glob checks run in a parent build and the child (real) build is invoked recursively.
  4. If globbing fails, you will have a difficult time figuring out which extra source file got added or removed.
  5. Globbing, especially recursive globbing, can be slow and gets worse the more files you have. Ext4's performance is typically acceptable, but NTFS's is bad, especially through Linux drivers. See: https://github.com/alexreinking/cmake-glob-performance/
  6. Globbing is particularly likely to fail when doing git bisects, switching branches, or performing other source control operations that move file timestamps backward.

1 Here's what the CMake developers have to say about it:

Note: We do not recommend using GLOB to collect a list of source files from your source tree. If no CMakeLists.txt file changes when a source is added or removed then the generated build system cannot know when to ask CMake to regenerate. The CONFIGURE_DEPENDS flag may not work reliably on all generators, or if a new generator is added in the future that cannot support it, projects using it will be stuck. Even if CONFIGURE_DEPENDS works reliably, there is still a cost to perform the check on every rebuild.


提交答案