How to use all *.c files in a directory with the Cmake build system?

MakefileCmake

Makefile Problem Overview


I want to find all .c files under a directory and add them all to SRC files to compile in cmake. How can I do this in CMakeList.txt.

for regular makefiles I can create

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

but I couldn't get how to do something like this in CMakeList.txt.

Makefile Solutions


Solution 1 - Makefile

How about the good old globbing?

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

Solution 2 - Makefile

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.

Solution 3 - Makefile

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.

Solution 4 - Makefile

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.

Solution 5 - Makefile

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})


           

Solution 6 - Makefile

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).

Attributions

All content for this solution is sourced from the original question on Stackoverflow.

The content on this page is licensed under the Attribution-ShareAlike 4.0 International (CC BY-SA 4.0) license.

Content TypeOriginal AuthorOriginal Content on Stackoverflow
Questionuser256537View Question on Stackoverflow
Solution 1 - MakefileDat ChuView Answer on Stackoverflow
Solution 2 - MakefilewhitequarkView Answer on Stackoverflow
Solution 3 - MakefileCiro Santilli Путлер Капут 六四事View Answer on Stackoverflow
Solution 4 - MakefileAlex ReinkingView Answer on Stackoverflow
Solution 5 - MakefileGPrathapView Answer on Stackoverflow
Solution 6 - MakefileJesperEView Answer on Stackoverflow