I have a custom C compiler that has a dedicated folder "include" where all .h and .c files should go. But it is missing all standard libraries. What is the quickest way to get all the include files for libraries like stdio and stdlib etc on the internet? I found websites offering separate .h or .c files for download, but is there one that offers the full collection of dependencies? Thanks for any suggestion!
Related
So I have a shared.h file, and a sharedprocess1.c and a sharedprocess2.c file. The .c files share declarations from the header but otherwise they do completely different things. I want to make a Makefile so i can run one OR the other but they both share the same .h file. How can i do this?
I am building a small library of my own *.c & *.h files and am not sure how I should manage them, especially when including them into a project. I'm using Codeblocks on Ubuntu in case that matters. For each .c/.h file pair, I have a Codeblocks project that is a playground where I can modify & test out any changes or newfound bugs.
I'm thinking I should compile the .c into libraries (.a/.so), put them into respective custom 'XXX/bin' and 'XXX/include' folders, and include/link from those locations (add to the PATH).
The other option (which I've been doing for right or wrong) is to add the .c file directly to my project and #include the full path of the .h file (I know this is wrong, but it works).
How do you all manage your .c and .h files?
Actually, both ways (prepare object files and use headers with them when compile program, and add source code and headers to each project with full or relative path) are quite normal. You should choose a way that is convenient for you. I do not know how Codeblocks works, but I suppose that as most IDE it can support dependencies, optimize build time and rebuild libraries (components of complex project) if some files were updated.
My suggestion is to consider some project build tools (project makers) like cmake. You will be able to configure building process for any project and to use different compilers, as well as different compiling options for different projects, while source files (*.c and *.h) storage is unchanged.
Start from cmake tutorial and other documentation
Of course, at first it will be not easy to deal with the makefile syntax, but when you get used to it you will realize how much it's convenient.
I think it is possible to include headers from their exact source, on a linux platform at least.
assume that you put your *.h in /usr/include you can just use
#include "/usr/include/*.h"
w/o moving your source files you can add the same chunk of code to every new sources you write, but VolAnd's above mentioned suggestions are probably more standard ways of managing.
Recently I have been working with the TIVA C series launchpad board which has a Cortex-M4 chip on it. I use the Code Composer Studio as my IDE.
There is a lot of confusion going on right now because through trial and error I see that in order to use certain functions that the chip manufacturer provides, I will need to include the .c file instead of including the .h file.
This caught me off guard and I admit that I am not an expert programmer or an expert when it comes to compiler design. But does anyone know why a compiler would need the .c file instead of needing the .h file?
The .h file is still being used since it has definitions in it that the .c file requires.
Perhaps a better question may be this:
When there is a .h file and a .c file, do you include the .c file in your code or do you include the .h file?
My trial and error exercise is telling me that you must include the .c file but I am totally in the blind on what the actual rules are.
Sorry if any part of this is too vague. I would be totally fine with sharing my main.c file so you can see how I included the files but I felt that my question is more of a question regarding what the general rules are for including files when there is both a .h and a .c file.
Thank you for any time you can give me in helping me understand this issue.
EDIT: Why the down votes? I thought coming here for help was what this place was about?
It is important to understand that substantially all C programs are built from multiple source files. Under some circumstances many of those sources are pre-compiled into one or more libraries, but it is quite common that building a C program will involve also building multiple C source files and linking those to each other and to appropriate libraries to produce the final result.
It is also important to understand that although C permits multiple compatible declarations of functions and file-scope variables, it permits only one definition of each distinct function or variable anywhere in an entire program. This is the primary reason for the convention of placing declarations into header files (ordinarily named with a .h extension). Any number of source files that contribute to a given program may #include the same header file, but at most one of them could #include the source file that contains the corresponding definitions, and then only if that file were not included directly in the build.
It may be possible to write your main source file so that it #includes the .c files containing all the needed definitions directly, in which case it is not necessary to include the headers, but you cannot have two separate source files doing that contribute to the same program if that produces duplicate function definitions. Ultimately, too, this approach may fail, for there can be limits on how large and complex a source file a given compiler can manage.
If there are header files accompanying the chip manufacturer's C source files, then your own source files should include only those headers. You should be able to build object files from such sources just fine. To build executable programs, however, you must also build the chip manufacturer's C sources, and link them to your own. It would be sensible to create a library containing the chip manufacturer's sources and to link that, but it would also work to build the needed source files directly for every program. Your IDE should have support for both options.
A friend at work told me today that
It is a known convention to not add header files to the project file in C project.
I was shocked and couldn't find any logical reason for this(because I felt that this convention would just make it difficult to reach the file I need).
He explained it as that the H file doesn't really contain compilable C code, so it is not "part of the project", but just meta data.
FYI - we work currently on an embedded project.
For example - project file could be - eww file with IAR workbench, or vcxproj in visual studio, or cproject file with eclipse
Does any one ever encountered this kind of convention, and could say how popular is it and what is the practical advantage/logic of it?
I don't believe this is a convention. Header files describe the interfaces between parts of your program, which I would argue is more important than the specific bits of code for many projects. If you move into C++, you may also find significant portions of the project's code implemented in headers to support templates in older C++ versions.
Your IDE is meant to keep the code you're using front and center, so you can access the source that you need and edit any code while minimizing context switching.
My advice: Add the headers to your project, but categorize them in a separate folder, filter group, or other mechanism to make them easy to access. Make sure they're visible to the compiler, set their build targets to not compile (since they're just being included) and you should be set.
There are no disadvantages of adding a header file to the project.
Some advantages I find:
If I create 'Source Files' , 'Header Files' etc folders and and add the respective files to the folder,it looks neat when you open the project in your IDE as I can directly see what are the header files being used in my project (which most of the times are created by you)
In some IDEs (eg MSVC) , I can search the header file directly using the search window if that header file has been added to the project.Otherwise I need to open one of the C/C++ files which includes this header and has to open the file from the line where #include is defined for that file.
So it is upto you , whether you need everything organized . depending your IDE etc , you can add/exclude header files to the project.
Hope this helps.
The only reason I can think of to not include .h files in your project file is if they aren't a part of your project. For example stdio.h. I have seen people do this before and it can cause problems. The main issue is that is can make your project non-portable. It can also lead to people accidentally modifying files that they shouldn't.
Is it possible that's what your friend was talking about?
Based on your comments, looks like one counter-example is enough to show that .h files are sometimes included in project files. Here's an example of a Qt qmake .pro file for a project, which lists header files:
TEMPLATE = app
CONFIG += console
CONFIG -= app_bundle
CONFIG -= qt
SOURCES += main.c \
module.c
HEADERS += \
module.h
To get that, I used Qt Creator first to create the project as "plain C project", then generated the module.h and the module.c stubs with Qt Creator, which added both to the .pro file. Now having the .h files in the .pro is optional: project would compile without it, but it would be harder to navigate the project etc, and I'd have to manually remove each .h from .pro after generating them.
As a complete opposite, I think there are build systems (with their project files) also for C projects, where you don't actually need to list any files. You just list directories, or even have standard directory layout, and the build system will scan the directories and compile the project according to it's rules. I think this is possible with cmake at least. And of course for many project file types (like plain Makefiles) you can use wildcards to find all .c files in a directory.
As to reasons why .h files would not be listed:
Compiler will find the .h files based on #includes, they are not given in command line (only include directories are given).
A modern IDE will scan the sources anyway and find all the used include files without them being listed.
If .h file lists are maintained manually, but per above two points nothing will actually fail if one is forgotten, then the list in project file may get out of date, when someone just forgets either to add or remove one when there are changes.
Listing build dependencies for each .c file is actually a bit different than just listing the .h files in project files, and is best handled automatically.
Using a version control should remove any ambiguity between files which are really part of the project even if they are not used (because they are in version control), and which are just some clutter which should be removed/ignored.
So, if having .h files listed in a project file is any extra work, and if it does not offer any concrete advantage (for example with some IDE), then a convention of just not having them seems sensible.
We have been learning C and it might seem like a stupid question to ask.
I want to know who exactly writes header files. I know that they have predefined functions in them and can be accessed as per need.
The header files that come with your compiler are written by the authors of your compiler and C library. Header files for third-party libraries are written by the authors of those libraries. Header files for your software are written by you.
Header files are written by the programmers to export the library functions or class. Header files may used to define classes, macros , member functions, structures, variables etc. if you make some changes in header files of your library it may affect your library functions. You have to recompile the library before use.