How are .Po files created in Makefile? - c

I have changed Makefile of a project and now when I make it, it returns:-
ERROR: "make[2]: *** No rule to make target ../libvmi/driver/.deps/xen.Po. Stop. "
How does Makefile create .Po files and how can I disable creating it for a certain file like ../libvmi/driver/.deps/xen.c?

.Po files are used as part of automake's dependency tracking. They are usually created by config.status as empty files, which get overwritten by actual dependencies when the compiler is invoked. (automake's approach is to do dependency generation as a side-effect of compilation.)
I've found that running make -k (-k is short for --keep-going) will be enough to unstick the build, once the file whose .Po is missing has been recompiled.

Automake uses dependencies for compilation by default. Dependencies are created in the .deps/ folder with the extension .Po.
Dependencies can be disabled. For various methods on turning dependencies off, see https://www.gnu.org/software/automake/manual/html_node/Dependencies.html
In my Makefile.am, I added the no-dependencies flag which prevents the .deps/ folder and .Po files from being created.
AUTOMAKE_OPTIONS = subdir-objects no-dependencies

Related

How does CMake add_executable work internally (dependencies and automatic source discovery)?

I am working on my first CMake/C project and I crossed a problem with my build that makes me re-question how compilation work.
I would like people to explain to me what exactly happens when you call add_executable and how make builds C file dependencies.
What I thought
I thought that, when calling add_executable (name, sources), CMake would see sources as a superset of the necessary source files to build the target name. So internally, he analyzes the REAL MINIMAL dependencies, by analyzing the file containing main, and recursively adding the included .h files, with their associated declarations in the .c files.
What seem to happen (I want confirmation)
CMake sees sources as the real minimum dependencies for the executable. It seems it will compile ANYTHING in sources, whether or not it is used anywhere.
Consequence
This for me is really annoying. In my project I use source discovery, meaning that anything in the src directory is added to the sources. Then, if I want to compile a unit test (make this_unit_test), it is, in fact, going to compile every .o file in my source directory instead of compiling the necessary files only. Which means that if something does not build in a part of my project, I can not build any tests anymore.
What can I do?
If CMake is indeed done in a way that you need to specify yourself the minimal dependencies for any executable, how can I still use automatic source/test discovery? The best solution would be from the CMakeList file, a function that takes a list of source files, and return the subset of it corresponding to what is actually included at some point by the file containing main. What do people do to resolve that problem?
No, CMake does not scan for minimal source dependencies for your executable, and how could it? CMake doesn't scan the source files, and has no knowledge about what includes/definitions your executable ultimately needs or doesn't need. This functionality would have to happen at the compilation stage (after CMake completes), because it is the pre-processor/compiler that parses your source files and interprets them for semantics (meaning). There are static analysis tools out there that can help achieve something like this, such as include-what-you-use.
Using source discovery techniques in CMake (such as file(GLOB ...)) can be error prone:
As you have seen, the source discovery mechanism may grab files that you do not need for building a particular target.
Even worse, source discovery may leave out files that are required for building a particular target.
The CMake documentation itself even warns against doing this!
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.
As a general rule of thumb, it is always safest to list each individual file that is required for each target explicitly, for example:
add_executable(MyExe
main.c
MyHelperFunctions.c
MyOtherStructs.c
)

CMake: Header files cannot be opened

I am working to build a Code Composer Studio project using cmake, which is new to me. It builds successfully under Linux but I am struggling to get it to work under Windows. The cmake command executes without issue, but make fails during the very first C object at the very first #include with the error code
fatal error: could not open source file "stdbool.h" (no directories in search list)
I'm using the libraries included in CCS's compiler (c6000_7.4.15), and that whole folder is included in the CSS project. I include it in cmake as well. In my .cmake file:
set (CCS_ROOT ${CCS_ROOT_V6_WIN} CACHE PATH "code composer install directory")
set(CGT_COMPILER_ROOT ${CCS_ROOT}/tools/compiler/c6000_7.4.15 CACHE INTERNAL "DSP Compiler Root")`
And in the CMakeLists.txt file:
set (COMPILER_INCLUDE ${CGT_COMPILER_ROOT}/include)
INCLUDE_DIRECTORIES ("${COMPILER_INCLUDE}")
Why can the header files not be opened when they're linked in the project and CMake can find them just fine?
EDIT: The directory structure had been changed underneath me, so I took the opportunity to add all of the external files directly into the project to make it completely platform-independent. That way, since the project is managed by our Git repository, users won't have to install the CSL or any other programs to build the project. This also means that paths to libraries and header files will never change between revisions and environments.
Unfortunately, this has not solved my problem. The project continues to build in Linux while failing to ind the very first included header file. I also notice that, under Windows, it cannot find my own header files unless I provide a relative path, e.g. #include "../Common.h" I can get make to find stdbool.h if I provide an absolute path to the compiler directory, but that exposes a web of additional broken links between files.
As a side note, the project builds successfully within Code Composer Studio, so I am assuming that this isn't an issue with my specific Windows environment nor with the code within the project itself.
This seems to be an issue with gcc.exe. I set an environment variable CC to the path of a different compiler (in my case a TI compiler) within my build script and that fixed the problem.

how to recompile include files in eclipse

i want to recompile my include files of my project,which includes some header files and .c source files which are files for my Ethetnet driver. Now i want some change in one of my included source file. but when i change and build or rebuild my project, the change in the include .c source file does occur in the final output binary. that means my project taking previously compiled included .o files. So how can i recompile my all include files of the project so that change occur in final output binary.
Thanks in advance.
CMIIW but AFAIK it depends on your compiler (which I guess is gcc), dependency analysis against included files may be done or not, and in gcc case it does NOT do it. It only compares .c against its corresponding .o, so you have to force rebuilding when you change the include file. There perhaps certain compiler options you can use, but I don't know for it.
EDIT:
Just found a similar question: How can I have a Makefile automatically rebuild source files that include a modified header file? (In C/C++)
If you are indeed including the right file (the ones that you have modified, not some with same name from some other directory) then cleaning a project and rebuilding it should help. Just select a project in project explorer, right click, do "clean project", then build it...

Autocreate directories when building

I have a project written in C and I am using mercurial (I can use git too) for version control and GNU make for building. The project includes several empty directories used for build-time generated files, such as dependency makefiles and object files.
When I check out the project, however, empty directories are not created (they are ignored by the version control system) and the build fails.
The only remedy I have in mind is to add a mkdir -p directive in every single recipe in the 58 makefiles of the project (it is quite big). Apart from a lot of editing, mkdir -p is discouraged in the GNU make manual for being incompatible with other versions of make.
Is there any smarter way to overcome the problem?
Both git and Mercurial track files, not directories, so empty directories will not be stored.
The common trick is to just add an empty file to the directories you need, like:
touch output/.empty
And then add that to the repository.
You can have:
output/%: output/.empty
output/.empty:
$(MKDIR_P) output
touch output/.empty
in the makefile. Than all files in output will depend on creating the directory without modifying each rule separately.
The $(MKDIR_P) definition (mkdir -p for most systems or a special script where that does not work) can be provided by configuration script (e.g. autoconf using AC_PROG_MKDIR_P) or conditional setting in the makefile.
As you mention that you could use git as well, maybe that you would be interested by the fact that bazaar can track directories the same way it does for files. I don't know if it is an option for you, just saying.

qmake -project: add new file extensions

I'm using QTCreator as a code editor for my C++ project, not using the real features of the qmake compilation process.
My project has several subdirectories, in all of which I ran qmake -project to create a duummy .pro file that simply lists the source and header files in the directory.
In my root folder, I simply created a "main.pro" file that includes all these "subdir/subdir.pro" files.
So it looks like this:
./
main.pro
subdir1/
/include
/src
subdir1.pro
subdir2/
/include
/src
subdir2.pro
Now my problem is, I use some files that have a special file extension (say, .ccp), which are actually some C code but are used in a different step of my compilation process.
They are naturally ignored by the qmake -project command and do not appear in my project.
I read here that I could use the qmake setting QMAKE_EXT_CPP to tell it to gather my files as a C-code file, but it doesn't seem to be working.
If I run qmake -query QMAKE_EXT_CPP, I get .cpp::.c::.ccp (which I set right before), but when running a new qmake, it doesn't take my .ccp files in account.
So, three questions:
Is it possible to make qmake take some special extensions as a C++ file, when building the .pro file?
If yes, is it correct to use the QMAKE_EXT_CPP setting?
If yes, what should be the syntax of the QMAKE_EXT_CPP setting? (mine inspired by this forum post, but it might be bogus).
You cannot change QMAKE_EXT_CPP with -project option. The list of cpp extensions used at this stage is hardcoded into qmake. However after initial creation of .pro file you can edit it to extend with support for other extensions:
in test.pro
QMAKE_EXT_CPP += .ccp
SOURCES += test.ccp
You have to add new files manually.

Resources