0

I am not an expert C or C++ programmer, but I have to write a C and a C++ application for two course projects. To start off on the right foot, I was reading a guide about how to structure the code of a CMake project.

I would like to clarify the meaning and usage of the include directory:

  • If the project is a library, is the include directory meant to contain the API functions that the users of the library can include in their code and invoke? If so, what directory should be used for headers containing declarations of internal functions? Should such headers be put together with the source code (which is contained in the src directory)?
  • If the project is an application, is the include directory meant to contain the header files of the source code? If so, what is the advantage of separating headers from sources? Is it just a matter of preference of organization?

Thank you for any insight.

Jason
  • 36,170
  • 5
  • 26
  • 60
steddy
  • 146
  • 1
  • 9
  • Help me understand. You need to write two applications, one in C and the other in C++? – Thomas Matthews May 13 '22 at 21:17
  • There is no single standard for include or source directory. I like to keep the source and includes in a directory based on a theme. One of my teammates change the organization and decided to put all include files in a separate directory (under the themed folder). The "include" directories usually include header files which contain declarations and maybe constants. – Thomas Matthews May 13 '22 at 21:20
  • Exactly; they are for two different courses. One (C) is about parallel computing in MPI/OpenMP, the other (C++) deals with CUDA – steddy May 13 '22 at 21:21
  • There is no "modern CMake structure" and I, for example, would never use the structure described by the link. So choose whatever suits you and go for it. – ixSci May 14 '22 at 05:27
  • This is less of a cmake question rather than a general one. It's indeed a good idea to keep the type & function declarations for types and functions used by targets linking your lib in a seperate directory. `include/libname` (e.g. `#include "opencv2/imgproc.hpp"`) is the defacto standard for installed libs, so choosing the same structure in your project can be a good idea. As for internal headers there is no standard; I usually put them right next to the implementation files to shorten relative includes. – fabian May 14 '22 at 08:16
  • Headers of executable targets should be treated the same way as internal library headers. For executables the user doesn't need access to any headers. The info in the headers is no longer needed in the build process after the compiler is done with your translation units and since noone will be linking your executable target, the headers of the executable targets have the same purpose as internal headers in a library target. – fabian May 14 '22 at 08:22

1 Answers1

1

If you are writing an application, you can put stuff wherever you want. The user mostly expects you to have a bin subdirectory with your binary executables. Oh, and please support the CMAKE_INSTALL_PREFIX: in-source builds are evil, as far as I'm concerned.

If you are writing a library, the user expects subdirectories include and lib in the install prefix location. For nice unix-y stuff you can include man if you know how to generate troff.

About the include directory. You can put your mylib.h file directly there, but if your library has at all a common name, say format, that may give name clashes, so these day many package organize it as /home/mylibinstallation/include/mylibrary/mylib.h. You would then export MYLIBINC=/home/mylibinstallation/include and the program would `#include "mylibrary/mylib.h". That extra level is also good if you have multiple includes.

Victor Eijkhout
  • 5,088
  • 2
  • 22
  • 23