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...
Related
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
)
I'm pretty new to coding in c, but I have sample code that I imported into the eclipse console. However, when I go to build the project I run into various errors. All of these errors are because a code that I have in one folder is not able to access code in another folder. For example my main function is located in project>src>main.c but is not able to access the project.h file located in project>headers>project.h. I am also no able to access code directly above in the hierarchy either. For example, my project>src>compiler>comp.h is not able to access project>src>calc.h file. Is there a way I can instruct the code to find it? I have tried using #include "../src/calc.h" in my comp.h file but I still get the error message "No such file or directory." Any suggestions would be very helpful.
Header files can be tricky to include, it depends where you are compiling.
Try to compile like this :
gcc -o myBinary <your .c files> -I./your/path/to.h (it will link your .h files at the compilation state)
The best idea would be to create a Makefile and configure it to make your header files works in every files of your project, have a look at How to create a Makefile.
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
I'm working on a project from school, and we were given a .o and a corresponding .h file.
We need to use several functions from the .o file in our .c program.
Just placing it in the same directory doesn't work.
I tried to look for something like this in the project properties, but no good.
I keep getting ../code_files/Search.c:116: undefined reference to 'reportError'
I'm using Eclipse (Juno) CDT, gcc MinGW under Windows 7
I know it's possible to include .a files, but I couldn't find any indication on how to include a .o file
#include "ErrorHandle.h" is included in the main c file.
Anyone knows how to include a .o file to a project?
Thanks!
I found this answer:
I tried doing something similar, only I didn't think of the miscellaneous thing
You can trivially turn the .o into a .a with ar cvs library.a object.o, and then add the .a to your project.
I'm sure this question has been asked many times, but I can't figure this out. Bear with me.
So when you download a library, you get a bunch of .c and .h files, plus a lot of other stuff. Now say you want to write a program using this library.
I copy all the .h files into my project directory. It just doesn't compile.
Great, so then I get the library as a bunch of .dll's, and i copy the dlls into my project directory. Still doesn't compile.
How does this work?
What do you do, like right after creating the folder for your project? What parts of the library package do you copy/paste into the folder? How do you make it so that it can compile? Go through the steps with me please.
Where to put the .h files?
Where to put the .dll files?
How to compile?
Thanks.
(the library I'm trying to get working is libpng, I'm in windows with MinGW, and i'm looking to compile from command-line like usual.)
(from what i gather, you put the .h files in directory A and the .dll files in directory B and you can use -l and -L compiler options to tell the compiler where to find them, is this correct?)
Here's a brief guide to what happens when you compile and build a basic C project:
The first stage compiles all your source files - this takes the source files you've written and translates them into what are called object files. At this stage the compiler needs to know the declaration of all functions you use in your code, even in external libraries, so you need to use #include to include the header files of whatever libraries you use. This also means that you need to tell the compiler the location of those header files. With GCC you can use the -I command line to feed in directories to be searched for header files.
The next stage is to link all the object files together into one executable. At this stage the linker needs to resolve the calls to external libraries. This means you need the library in object form. Most libraries will give you instructions on how to generate this or might supply it ready built. Under Linux the library file is often a .a or .so file, though it might just be a .o. Again you can feed the location of the library's object file to GCC with the -L option.
Thus your command line would look like this:
gcc myProg.c -I/path/to/libpng/include -L/path/to/libpng/lib -lpng -o myProg.exe
(Note that when using the -l command line GCC automatically adds lib to the start of the library, so -lpng causes libpng.a to be linked in.)
Hope that helps.
Doing it under windows (supposing you user Visual Studio)
After unpacking add the library include directories to your projects' settings (Project -> Properties -> C/C++ -> Additional Include Directories)
Do the same thing for the Libraries Directory (Project -> Properties -> Linker -> Additional Library Directories)
Specify the name of the library in your Linker Input: Project -> Properties -> Linker -> Input -> Additional Dependencies
After this hopefully should compile.
I don't recommend adding the directories above to the Global settings in Visual Studio (Tools -> Options -> Project and Solutions) since it will create and environment where something compiles on your computer and does NOT compile on another one.
Now, the hard way, doing it for a Makefile based build system:
Unpack your stuff
Specify the include directory under the -I g++ flag
Specify the Library directory under the -L g++ flag
Specify the libraries to use like: -llibrary name (for example: -lxml2 for libxml2.so)
Specify the static libraries like: library name.a
at the end you should have a command which is ugly and looks like:
g++ -I/work/my_library/include -L/work/my_library/lib -lmylib my_static.a -o appname_exe MYFILE.CPP
(the line above is not really tested just a general idea)
I recommend go, grab a template makefile from somewhere and add in all your stuff.
You must link against a .lib or something equivalent i.e. add the ".lib" to the libraries read by the linker. At least that's how it works under Linux... haven't done Windows so a long while.
The ".lib" contains symbols to data/functions inside the .dll shared library.
It depends on the library. For examples, some libraries contain precompiled binaries (e.g. dlls) and others you need to compile them yourself. You'd better see the library's documentation.
Basically, to compile you should:
(1) have the library's include (.h) file location in the compiler's include path,
(2) have the library stubs (.lib) location in the linker's library path, and have the linker reference the relevant library file.
In order to run the program you need to have the shared libraries (dlls) where the loader can see them, for example in your system32 directory.
There are two kinds of libraries: static and dynamic (or shared.)
Static libraries come in an object format and you link them directly into your application.
Shared or dynamic libraries reside in a seperate file (.dll or .so) which must be present at the time your application is run. They also come with object files you must link against your application, but in this case they contain nothing more than stubs that find and call the runtime binary (the .dll or the .so).
In either case, you must have some header files containing the signatures (declarations) of the library functions, else your code won't compile.
Some 'libraries' are header-only and you need do nothing more than include them. Some consist of header and source files. In that case you should compile and link the sources against your application just as you would do with a source file you wrote.
When you compile, assuming you have the libs and the headers in the same folder as the sources you are compiling, you need to add to your compile line -L . -I . -lpng. -L tells the linker where to look for the library, -I tells the compiler where to look for the headers and -lpng tells the linker to link with the png library.
[Edit]
Normal projects would have some sort of hierarchy where the headers are in an /include folder and the 3rd party libs are in a /libs folder. In this case, you'd put -I ./include and -L ./libs instead of -I . and -L.
[Edit2] Most projects make use of makefile in order to compile from the command line. You can only compile manually for a small number of files, it gets quite hectic after that
Also,
you may want to look over Dynamic Loading support in various languages and on various
platforms.
This support is very handy in cases when you want to use a library optionally and you don't want your program to fail in case that library is not available.