I would use vera++ to analyse several C libraries that I developed.
These libraries are contained into 4 different folders and there isn't a main.c file.
It is possible to check the libraries code with vera++? Or vera++ requires the main.c?
Thanks
To check a file .c or .h run vera++ as
vera++ my_file.c
If you want to run only specific rules you can do
vera++ -R T013 my_file.c
I use the following to run vera++ on all files in src/ and include/ matching *.c and *.h
find src/ include/ -type f -regextype sed -iregex ".*/*\.\(c\|h\)" -print | xargs vera++
Related
I am trying cross compile C code (outside yocto) using toolchain (/home/amruta/Downloads/poky-glibc-x86_64-core-image-weston-sdk-cortexa7hf-neon-toolchain-2.4.2.sh) for renesas G1E module. Procedure followed to cross compile :
Installed given toolchain
Set environment :
amruta#amruta-OptiPlex-3060:~$ . /opt/poky/2.4.2/environment-setup-cortexa7hf-neon-poky-linux-gnueabi
Compiling in same terminal :
amruta#amruta-OptiPlex-3060:~/amruta/amruta_projects/G1E/EnergyMeterApp1/src$ $CC *.c -o Energymeter -L /opt/poky/2.4.2/sysroots/cortexa7hf-neon-poky-linux-gnueabi/usr/lib/libmosquitto -I /opt/poky/2.4.2/sysroots/cortexa7hf-neon-poky-linux-gnueabi/usr/include/
Source files used for cross compilation :
amruta#amruta-OptiPlex-3060:~/amruta/amruta_projects/G1E/EnergyMeterApp1/src$ ls
client_shared_lib.c EnergyMeterApp1.h GenericFunctions.c modbus ProcessHandler.c
client_shared_lib.h FileLogger.c GenericFunctions.h mosq_pub_sub_client.c ProcessHandler.h
FileLogger.h libconfig.h mosq_pub_sub_client.h ReadAllConfigs.c
EnergyMeterApp1.c GenericDefns.h Makefile mosquitto.h ReadAllConfigs.h
Library files already present in lib dir
amruta#amruta-OptiPlex-3060:~$ ls /opt/poky/2.4.2/sysroots/cortexa7hf-neon-poky-linux-gnueabi/usr/lib | grep libmos
libmosquitto.so.1
amruta#amruta-OptiPlex-3060:~$ ls /opt/poky/2.4.2/sysroots/cortexa7hf-neon-poky-linux-gnueabi/usr/lib | grep libconf
libconfig.so.9
libconfig++.so.9
libconfig.so.9.2.0
libconfig++.so.9.2.0
amruta#amruta-OptiPlex-3060:~$
Header files present in include dir
amruta#amruta-OptiPlex-3060:~$ ls /opt/poky/2.4.2/sysroots/cortexa7hf-neon-poky-linux-gnueabi/usr/include/ | grep mos
mosquitto.h
amruta#amruta-OptiPlex-3060:~$ ls /opt/poky/2.4.2/sysroots/cortexa7hf-neon-poky-linux-gnueabi/usr/include/ | grep libconfig
libconfig.h
Build output (partial):
amruta#amruta-OptiPlex-3060:~/amruta/amruta_projects/G1E/EnergyMeterApp1/src$ $CC *.c -o Energymeter -L /opt/poky/2.4.2/sysroots/cortexa7hf-neon-poky-linux-gnueabi/usr/lib/libmosquitto -I /opt/poky/2.4.2/sysroots/cortexa7hf-neon-poky-linux-gnueabi/usr/include/
/tmp/ccBMhPYg.o: In function client_id_generate':
client_shared_lib.c:(.text+0x64): undefined reference to mosquitto_lib_cleanup'
client_shared_lib.c:(.text+0x144): undefined reference to `mosquitto_lib_cleanup'
/tmp/ccRMPfVp.o: In function ReadEnergyMeterConfigs':
ReadAllConfigs.c:(.text+0x374): undefined reference to config_init'
ReadAllConfigs.c:(.text+0x384): undefined reference to config_read_file'
ReadAllConfigs.c:(.text+0x3c8): undefined reference to config_destroy'
Please suggest for successful cross compilation.
Specifying a library directory (-L <dir>) will not cause any libraries therein to be linked. The -L switch only tells the linker where to look for libraries specified by -l <lib> switches, of which you have none.
You need to add -l mosquitto to link libmosquitto.so for example. Similarly -l config for libconfig.so.
In general for any library libXXX.so or libXXX.a you link it with -l XXX. Where the libraries are versioned as in this case, the latest version will be linked. To link a specific version, you don't use -l <lib> but simply specify the path to the specific .so file as an input without a '-' switch.
I have a folder called UnitTest. I have several .c files in it. All files contain function 'main'.
Using makefile, I want to compile all .c files of that folder together.
But these files have dependency on other C files which are in different folder.
How can I write make file for this?
eg.
Common\*.c - generate object file
App\*.c - generate object file. - refers to .o files of Common directory
UnitTest\.c - these files should be compiled as executables. Refer *.o from directory App and Common.
Update:
Header files are in seperate directory called \Include
I need a single makefile for this. Please help.
As per the standards every directory will contain one Makefile. So you can have three Makefiles for this job done if you have three directories.
(d) common
|
|---(f) common.h
|---(f) common.c
|---(f) Makefile --- MAkefile for the common folder.
(d) app
|
|---(f) app.h
|---(f) app.c
|---(f) Makefile
(d) unittest
|
|---(f) unittest.h
|---(f) unittest.c
|---(f) Makefile
(f) Makefile --- invoke all makefiles in the mentioned order.
If you want one Makefile to happen all these done, you can do in that way also. Here you have to compile the files by providing paths of the files. order is most impotent.
This is complicated, so we will take it in stages. First, building the object files:
CFLAGS += -I/include
vpath %.h /include
This should be enough to build any object file in Common/, Apps/ or UnitTest/. Test this before going further.
Now to build all of the objects in Common/:
COMMONSOURCES := $(wildcard Common/*.c)
COMMONOBJECTS := $(COMMONSOURCES:.c=.o)
all: $(COMMONOBJECTS)
Test this before going further.
Remove that all rule, and put in a rule for the Common library. (We'll use a static library for now, since it's a little simpler.)
Common/libCommon.a: $(COMMONOBJECTS)
ar -cvq $# $^
Test that much, tell us in the comments how it worked, then we'll build Apps library and the UnitTest executables.
This is the first time I install a library. I followed the instructions here. It's from an online course on programming.
I'm not very Unix savvy. When I tried to compile one of the sample c files, one that #includes the cs50.h file, I get:
cc1: error: /usr/local/include: not a directory
Also, if I write cd /usr/local/include or cd /usr/local/lib, it tells me it's not a directory again, even though when I ls /usr/local they both show up.
Any ideas?
Given that the instructions in the header are:
To compile as a static library on your own system:
% gcc -c -ggdb -std=c99 cs50.c -o cs50.o
% ar rcs libcs50.a cs50.o
% rm -f cs50.o
% cp cs50.h /usr/local/include
% cp libcs50.a /usr/local/lib
Note the use of '%' as a prompt. It indicates that the operations should be done as root.
Unless your system is misconfigured, you will need to use root privileges to copy the files into the directories under /usr/local. For example, you might use sudo as a prefix to the commands:
sudo cp cs50.h /usr/local/include
sudo cp libcs50.a /usr/local/lib
We can deduce (with fairly high confidence) that you did not already have directories /usr/local/include and /usr/local/lib, and that you now have two files (not directories) called:
/usr/local/include that contains the header cs50.h
/usr/local/lib that contains the static library
You should validate this observation with ls -l /usr/local and perhaps file /usr/local/*. Then you should remove the files, create the directories, and copy the files into the newly created directories.
The only thing this explanation does not account for is the missing leading slash in the error message (which originally said 'cc1: error: usr/local/include: not a directory'). At the moment, I put that down to a transcription error in asking this question. (And a comment and edit confirms that diagnosis.)
I've just started to learn C (using Thinking In C) and I'm wondering about what files I should be ignoring in a C project's git repository.
No suggestion can be too obvious -- I'm a total noob. Thanks!
I guess there will be a few generated files that you don't wan't to be sticking in your repo (assuming your build output dir is in your git heirachy):
object files (.o, o.obj)
libraries (.lib)
DLLs, shared objects (.so, .dll)
Executables (.exe, a.out ?)
GIT ignore files are something I tend to do iteratively. "Hey, I don't need those things in my repo" ...
Edit: re dmckee's comment
Yep, you definately want to be ignoring swap files, temp files etc. I have the following as a baseline for my .gitignore:
*.swp
.~
thumbs.db
You can also setup your build to happen in a subdirectory say build and then you can ignore the whole thing inside .gitignore
build/
And you're done.
I use this in my .gitignore
But I am building for micro-controllers, so I don't know if it helps you much.
The easiest way to know, is just do a make clean, then add all your files, then do a make all and see what extra stuff appears.
#Some of these are related to eclipse. So i keep them out of my repo
.cproject
.dep/
.project
.settings/
#files being edited
*~
# make and build files
*.lst
*.o
*.eep
*.lss
*.map
*.sym
# I keep these, since I prefer having the reference of the final build
# *.elf
# *.hex
Github's .gitignore file templates cover most of the common files for projects in a variety of languages.
The C .gitignore template looks like this:
# Prerequisites
*.d
# Object files
*.o
*.ko
*.obj
*.elf
# Linker output
*.ilk
*.map
*.exp
# Precompiled Headers
*.gch
*.pch
# Libraries
*.lib
*.a
*.la
*.lo
# Shared objects (inc. Windows DLLs)
*.dll
*.so
*.so.*
*.dylib
# Executables
*.exe
*.out
*.app
*.i*86
*.x86_64
*.hex
# Debug files
*.dSYM/
*.su
*.idb
*.pdb
# Kernel Module Compile Results
*.mod*
*.cmd
.tmp_versions/
modules.order
Module.symvers
Mkfile.old
dkms.conf
Using a *nix system and a Makefile, you could add each generated file to .gitignore.
As an example I use the following when creating an executable from a single source (Example for a C executable generation):
%: %.c
gcc -o $# $<
grep '^$#$$' .gitignore > /dev/null || echo '$#' >> .gitignore
The following line can be added to other recipes to add target $# to .gitignore file:
grep '^$#$$' .gitignore > /dev/null || echo '$#' >> .gitignore
Explanation:
grep '^$#$$' .gitignore : searches for the target in .gitignore
^ indicates start of line
$$ is a single $ (but Makefile needs $$ to work) and indicates the end of the line
'^$#$$' represents the target name
|| : executes the next command only if the left hand one failed
so only if grep ... does not find the target name in .gitignore, echo ... is executed
echo '$#' >> .gitignore: adds the target name to .gitignore
Eventually, you will add to clean and rebuild everything to make sure all files are correctly ignored
I'm a C Newb
I write lots of code in dynamic languages (javascript, python, haskell, etc.), but I'm now learning C for graduate school and I have no idea what I'm doing.
The Problem
Originally I was building all my source in one directory using a makefile, which has worked rather well. However, my project is growing and I would like to split the source into multiple directories (unit tests, utils, core, etc.). For example, my directory tree might look like the following:
.
|-- src
| |-- foo.c
| |-- foo.h
| `-- main.c
`-- test
`-- test_foo.c
test/test_foo.c uses both src/foo.c and src/foo.h. Using makefiles, what is the best/standard way to build this? Preferably, there would be one rule for building the project and one for building the tests.
Note
I know that there are other ways of doing this, including autoconf and other automatic solutions. However, I would like to understand what is happening and be able to write the makefiles from scratch despite its possible impracticality.
Any guidance or tips would be appreciated. Thanks!
[Edit]
So the three solutions given so far are as follows:
Place globally used header files in a parallel include directory
use the path in the #include satement as in #include "../src/foo.h"
use the -I switch to inform the compiler of include locations
So far I like the -I switch solution because it doesn't involve changing source code when directory structure changes.
For test_foo.c you simply need to tell the compiler where the header files can be found. E.g.
gcc -I../src -c test_foo.c
Then the compiler will also look into this directory to find the header files. In test_foo.c you write then:
#include "foo.h"
EDIT:
To link against foo.c, actually against foo.o, you need to mention it in the object file list. I assume you have already the object files, then do after that:
gcc test_foo.o ../src/foo.o -o test
I also rarely use the GNU autotools. Instead, I'll put a single hand-crafted makefile in the root directory.
To get all headers in the source directory, use something like this:
get_headers = $(wildcard $(1)/*.h)
headers := $(call get_headers,src)
Then, you can use the following to make the object-files in the test directory depend on these headers:
test/%.o : test/%.c $(headers)
gcc -std=c99 -pedantic -Wall -Wextra -Werror $(flags) -Isrc -g -c -o $# $<
As you can see, I'm no fan of built-in directives. Also note the -I switch.
Getting a list of object-files for a directory is slightly more complicated:
get_objects = $(patsubst %.c,%.o,$(wildcard $(1)/*.c))
test_objects = $(call get_objects,test)
The following rule would make the objects for your tests:
test : $(test_objects)
The test rule shouldn't just make the object files, but the executables. How to write the rule depends on the structure of your tests: Eg you could create an executable for each .c file or just a single one which tests all.
A common way of doing this is for header files used by a single C file to be named the same as that C file and in the same directory, and for header files used by many C files (especially those used by the whole project) to be in a directory include that is parallel to the C source directory.
Your test file should just include the header files directly using relative paths, like this:
#include "../src/foo.h"