When trying to run an analysis on my project with Splint via makefile I got this error message :
Cannot open file: ../splint_evaluationa/my_project/source/*.c
Finished checking --- no code processed
Here is my makefile:
SPLINT_FLAGS =-preproc \
-warnposixheaders \
SRCS=/home/user/splint_evaluationa/my_project/source/*.c
INC_FLAGS=-I/home/user/splint_evaluation/my_project/include
do_splint:
splint $(SPLINT_FLAGS) $(INC_FLAGS) $(SRCS)
You have a extra a, try that instead:
SRCS=/home/user/splint_evaluation/my_project/source/*.c
Related
I am new to ubuntu and hence to make file. I have successfully created make file with folder structure. However, if I add the similar structure, I get an error.
I successfully executed make command and ran application with one main cpp file and two files (list_menu.cpp and list_menu.h ) in sub folder cpp11_and_cpp14_menu
folder structure looks exactly like below where cpp11_and_cpp14.cpp has the main function.
../advancedcppproject/
cpp11_and_cpp14.cpp
Makefile
../advancedcppproject/cpp11_and_cpp14_menu
list_menu.cpp
list_menu.h
../advancedcppproject/multi_threading_example
multi_threading.cpp
multi_threading.h
Make file contents are
cpp11_and_cpp14 : cpp11_and_cpp14.o ./multi_threading_example/multi_threading.o ./cpp11_and_cpp14_menu/list_menu.o
g++ cpp11_and_cpp14.o ./multi_threading_example/multi_threading.o ./cpp11_and_cpp14_menu/list_menu.o -o cpp11_and_cpp14
cpp11_and_cpp14.o : cpp11_and_cpp14.cpp ./cpp11_and_cpp14_menu/list_menu.h ./multi_threading_example/multi_threading.h
g++ -c cpp11_and_cpp14.cpp
./cpp11_and_cpp14_menu/list_menu.0 : ./cpp11_and_cpp14_menu/list_menu.cpp ./cpp11_and_cpp14_menu/list_menu.h
g++ -c ./cpp11_and_cpp14_menu/list_menu.cpp
./multi_threading_example/multi_threading.o : ./multi_threading_example/multi_threading.cpp ./multi_threading_example/multi_threading.h
g++ -c ./multi_threading_example/multi_threading.cpp
After executing make command, it fails with an error message
g++ -c ./multi_threading_example/multi_threading.cpp
g++ cpp11_and_cpp14.o ./multi_threading_example/multi_threading.o ./cpp11_and_cpp14_menu/list_menu.o -o cpp11_and_cpp14
g++: error: ./multi_threading_example/multi_threading.o: No such file or directory
Makefile:6: recipe for target 'cpp11_and_cpp14' failed
make: *** [cpp11_and_cpp14] Error 1
I expect multi_threading.o to be created under folder ../advancedcppproject/multi_threading_example. However multi_threading.o is created under ../advancedcppproject.
Where as list_menu.o is correctly created under ../advancedcppproject/cpp11_and_cpp14_menu.
What is wrong?
Suppose I have the following files:
.: include/ 01.src 02.src 03.src Makefile
./include: 01.inc 02-source1.inc 02-source2.inc
for which I have the following Makefile (source: Complex pattern rule in Makefile):
exe = ${patsubst %.src, %.exe, ${wildcard *.src}}
all : ${exe}
.SECONDEXPANSION:
${exe} : %.exe : %.src $${wildcard include/%*.inc}
#echo compile $# using $^
This says that 01.exe will be compiled using 01.src and include/01*.inc (something similar for 02.exe and 03.exe). In fact, make outputs:
compile 01.exe using 01.src include/01.inc
compile 02.exe using 02.src include/02-source1.inc include/02-source2.inc
compile 03.exe using 03.src
My question is: How should I modify this Makefile if 01.src, 02.src, and 03.src are renamed to 01-first.src, 02-second.src, and 03-third.src? The desired output is:
compile 01-first.exe using 01-first.src include/01.inc
compile 02-second.exe using 02-second.src include/02-source1.inc include/02-source2.inc
compile 03-third.exe using 03-third.src
try this:
${exe} : %.exe : %.src $${wildcard include/$$(shell echo % | head -c 2)*.inc}
#echo compile $# using $^
output:
compile 03-third.exe using 03-third.src
compile 02-second.exe using 02-second.src include/02-source1.inc include/02-source2.inc
compile 01-first.exe using 01-first.src include/01.inc
I have the following Makefile entry:
TEST_DIRS = abcd pqr xyz
test_lib :
for dir in $(TEST_DIRS); do \
$(MAKE) -C $$dir; \
done
run :
./abcd/test/abcd_test.o --log_level=message
./pqr/test/pqr_test.o --log_level=message
./xyz/test/xyz_parser_test.o --log_level=message
test : test_lib run
I don't want to write 3 separate commands for run target instead make it generic. So that everytime a new test file gets added, I dont want add a new command under run target. Can somebody help me?
TESTS := $(addprefix TEST_, $(TEST_DIRS))
run: $(TESTS)
TEST_%:
./$*/test/$*_test.o --log_level=message
Assuming the naming scheme is consistent (and those are just oddly named binaries and not actually object files) then something like this should work:
Using a shell loop:
run :
for name in $(TEST_DIRS); do \
./$$name/test/$${name}_test.o --log_level=message; \
done
Using make foreach:
run :
$(foreach name,$(TEST_DIRS),./$(name)/test/$(name)_test.o --log_level=message;)
I am new to Erlang, so i am going through Joe Armstrong's book "Programming Erlang". In chapter 25 there's an example on how to work with rebar. I followed the instructions and created a Makefile
all:
test -d deps || rebar get-deps
rebar compile -v
#erl -noshell -pa './deps/bitcask/ebin' -pa './ebin' -s myapp start
and rebar.config
{deps, [
{bitcask, ".*", {git, "git://github.com/basho/bitcask.git", "master"}}
]}.
Getting the dependencies works, but compiling fails.
The verbose output tells me that this command fails
cmd: cc -c $CFLAGS -g -Wall -fPIC -I"/usr/lib/erlang/lib/erl_interface-3.7.18/include" -I"/usr/lib/erlang/erts-6.2/include" c_src/bitcask_nifs.c -o c_src/bitcask_nifs.o
with this error
/home/user/folder/deps/bitcask/c_src/bitcask_nifs.c:22:19: fatal error: errno.h: No such file or directory
But
find /usr/include -name errno.h
gives me
/usr/include/x86_64-linux-gnu/asm/errno.h
/usr/include/asm/errno.h
/usr/include/linux/errno.h
/usr/include/asm-generic/errno.h
So I was asking myself..
what am I missing?
how can I tell rebar about the depencies on the C libraries and where to find them?
why isn't this configured correctly in the Makefile of bitcask?
Maybe I was searching for the wrong terms, but I couldn't find any solution in the internets.
Many thanks in advance
There are two thing to consider
rebar options
You can set options for compiling C code with port_env option in rebar.config.
comiling deps
Since bitstack is your dependency, it is not compiled with yours rebar config, but with it's own. So if you would like to change anything, you would have to modify the bitcask file.
Fortunately, if you look into config their writen all C compilation is done with environment variable $ERL_CFLAGS. And again, in rebar source code you can see that this flag is responsible for include paths in your compilation.
So easist way would be extending $ERL_CFLAGS in your Makefile before compilation, with something like this
all: ERL_CFLAGS = "$ERL_CFLAGS -I /usr/include/linux/errno.h"
all:
test -d deps || rebar get-deps
rebar compile -v
#erl -noshell -pa './deps/bitcask/ebin' -pa './ebin' -s myapp start
Just make sure that this include works for you, and that you are not overwriting any flags you are using.
I encounter an error relating to implicit rule in make (3.81). The example codes are:
dongli:test02 dongli$ ls -R
Makefile a.F90 b.F90 dir
./dir:
a.t.F90
The dependencies among the codes are:
a.t.F90: a.F90
a.t.o: a.t.F90
b.o: b.F90
b: a.t.o b.o
That is a.F90 is intermediate code, and a.t.F90 will be updated when a.F90 is updated. My make process is:
Test 1 (All codes on position):
-------------------------------------------------------------
Project: >>> test <<<
-------------------------------------------------------------
Creating dependency a.t.o
-------------------------------------------------------------
-----> ./dir/a.t.F90
Creating dependency b.o
-------------------------------------------------------------
-----> b.F90
Creating target 'b'
---> b is created.
-------------------------------------------------------------
Finished
-------------------------------------------------------------
Test 2 (touch a.F90):
dongli:test02 dongli$ touch a.F90
dongli:test02 dongli$ make
-------------------------------------------------------------
Project: >>> test <<<
-------------------------------------------------------------
Processing templates in a.F90
-------------------------------------------------------------
Creating dependency a.t.o
-------------------------------------------------------------
-----> a.t.F90
gfortran: error: a.t.F90: No such file or directory
gfortran: fatal error: no input files
compilation terminated.
make: *** [a.t.o] Error 1
Test 3: (Run make again):
dongli:test02 dongli$ make
-------------------------------------------------------------
Project: >>> test <<<
-------------------------------------------------------------
Creating dependency a.t.o
-------------------------------------------------------------
-----> ./dir/a.t.F90
Creating dependency b.o
-------------------------------------------------------------
-----> b.F90
Creating target 'b'
---> b is created.
-------------------------------------------------------------
Finished
-------------------------------------------------------------
I know there is a bug in make about directory caching (see here), but in my case, dir/a.t.F90 exists all the time. Any idea? Thanks!
Update1:
I use make -d to capture the following information in test 2:
Finished prerequisites of target file `a.t.F90'.
Prerequisite `a.F90' is newer than target `a.t.F90'.
Must remake target `a.t.F90'.
Ignoring VPATH name `./dir/a.t.F90'.
...
Successfully remade target file `a.t.F90'.
Finished prerequisites of target file `a.t.o'.
Prerequisite `a.t.F90' of target `a.t.o' does not exist.
Must remake target `a.t.o'.
Why ./dir/a.t.F90 is ignored when its prerequisite a.F90 is newer than it?
Update2:
I have put the example codes on gist.
Update3:
I found the following relating information:
If a target needs to be rebuilt, GNU make discards the file name found
during the VPATH search for this target, and builds the file locally
using the file name given in the makefile. If a target does not need
to be rebuilt, GNU make uses the file name found during the VPATH
search.
You really need to show the rules that create these targets. You've provided a lot of information about many aspects of your build, but one of the most critical aspects of debugging make issues is seeing the rules.
Failures like this (where the first build fails and the second succeeds) are almost invariably due to rules that do not behave as you have described them to make. If you tell make that a rule builds a file "foo", by creating something like foo : bar, but then the recipe that you write doesn't actually create "foo" but rather "bar/foo", something like:
foo : bar ; cp bar bar/foo
then that is wrong. Another common reason for such issues is that you define a rule that builds "foo.x", but it also builds "foo.y" and you don't tell make about it but then later use "foo.y" as a prerequisite, that can't work. You have to define a rule that tells make that both those files are generated from a single invocation of the recipe, such as:
%.x %.y : %.z ; cp $< $*.x && cp $< $*.y
And finally, you mention VPATH above and it looks like you're trying to use VPATH to find generated files. That will not work. VPATH can only be used to find source files (files make doesn't know how to build and expects to always be present). Without seeing more about your makefiles and how the rules are constructed, that's about all we can say.
Edited to add:
I'm not sure it's really necessary to use so much eval and call here; often people seem to go straight to these very powerful tools when simpler ones would suffice just as well. In any event, the problem you're having is exactly as I suspected in my first comment above; you have this rule:
%.t.F90: %.$(1)
#echo " Processing templates in $$^"
#echo $$(seperator)
#cp $$< dir/$$#
Note the last line, where instead of creating $# you're creating dir/$#; this is precisely the situation I described above. Whenever you have a rule that builds something that is not exactly $#, it's almost 100% certain that rule is wrong. You need to write this as:
dir/%.t.F90: %.$(1)
#echo " Processing templates in $$^"
#echo $$(seperator)
#cp $$< $$#
and maybe more changes to match that target.
I make a workaround that I inserted some scripts in the implicit rule that add the missing directory part of the code, since VPATH has some constraints on this.
%.o: %.$(1)
#echo " Creating dependency $$#"
#echo $$(seperator)
#TEMPLATE_PATTERN='.*\.t\.$(1)'; \ <
if [[ $$$$(dirname $$<) == '.' && '$$<' =~ $$$$TEMPLATE_PATTERN ]]; then \ <
SRC=$(PROJECT_ROOT)/.codemate/processed_codes/$$<; \ <
else \ <
SRC=$$<; \ <
fi; \ <
$(FC) -c $$$$SRC $(OPTIONS) $(FFLAGS) $(INCLUDES)
labeled by <.