I have a Makefile that imports another Makefile that is generated by a target in the containing one. Something like the following:
more_makefile:
touch $#
include more_makefile
This process works fine, but you get a warning No such file or directory every time you hit the include line when more_makefile doesn't exist, which can confuse newcomers. Is there a way to mask this warning?
Add a hyphen:
-include more_makefile
Related
I am trying to run https://github.com/pavanpongle/IoT-Wormhole-IDS. After following README.md and Instructions to run, I understood that I need to use the Makefile. I have properly indented the file which now looks as below:
DEFINES+=PROJECT_CONF_H=\"project-conf.h\"
all:$(CONTIKI_PROJECT)
CONTIKI=../..
WITH_UIP6=1
UIP_CONF_IPV6=1
CFLAGS+= -DUIP_CONF_IPV6_RPL -DUIP_CONF_IPV6 -DWITH_UIP6
LDLIBS=-lm
ifdef PERIOD
CFLAGS=-DPERIOD=$(PERIOD)
endif
include $(CONTIKI)/Makefile.include
I have given execute permissions to the Makefile. After running make, the following message is displayed.
make: Nothing to be done for 'all'.
If CONTIKI_PROJECT should be assigned some value before all:, then what should it be?
I am not able to understand if I am missing anything from contiki point of view or it is just to do something with the Makefile.
How do I make this project work?
CONTIKI_PROJECT should refer to the name of your application, which is the same as the name of main .c file with the application's source code.
Here is the hello-world example Makefile from the project you linked to:
CONTIKI_PROJECT = hello-world
all: $(CONTIKI_PROJECT)
CONTIKI = ../..
include $(CONTIKI)/Makefile.include
I have a Makefile like so:
T:=$(shell mktemp)
include ${T}
I:=$(shell rm ${T})
all:
echo done
In theory, mktemp should create an empty file and return its name. The next line should include that file. The following line should delete it.
When I run it I get:
make: *** No rule to make target `/tmp/tmp.Cwe7kiNBA3'. Stop.
If I comment out the third line like so:
T:=$(shell mktemp)
include ${T}
#I:=$(shell rm ${T})
all:
echo done
The Makefile works as expected, but leaves the temporary file behind.
Why doesn't the original example work as expected?
Your Makefile seems good without the include ${T} command. As described by GNU, the include directive is useful to:
suspend reading the current makefile and read one or more other
makefiles before continuing.
So, the following Makefile:
T:=$(shell mktemp)
I:=$(shell rm ${T})
all:
echo done
will produce this output and it will not report errors:
echo done
done
Make is trying to remake your included Makefile - for example, it works if you replace include with -include (which doesn't complain when the remake fails). You can fix it by adding an empty recipe for it: ${T}: ;.
I am writing a makefile script which should be able to parse a file which is created by the same makefile. I am using following code to parse $(FileName) file. When I execute I see **cat: InputFile:No such file or directory**. This code works fine for already existed file, but not working if file is not exist before I run make. Could you please suggest how can I resolve this issue? Thanks in advance.
Snippet from the Makefile -
test_connection:
. . .
//Create file named $(Filename)
. . .
$(call generate_list,$(FileName))
define generate_list
$(eval FILE_DATA= $(shell cat $(DIR)/$1); \
$(foreach word, $(FILE_DATA), \
. . .
endef
Your problem is that you are crossing boundaries. make parsing and processing happens before any rule bodies are run. target rule bodies are only run after that. So you can't create a file in a target rule body and expect it to be available for usage during make context (without using an included makefile but we'll get to that in a minute).
The simplest solution to this problem is simply to move the parsing out of make entirely and just do it in a shell (or other) script. This obviously doesn't work if you need the contents for some make-level decisions/etc. though.
The other possible solution is to use an included makefile and take advantage of the fact that when make rebuilds an included makefile it will restart its processing from the beginning (which then makes the contents of that makefile available from the start). To do this you would:
add an include $(Filename) line in your makefile
create a $(Filename): target with a rule to build it
parse the file (when it exists) in the top-level of your makefile
do what you need with the parsed data (in some makefile variables I assume) in the test_connection rule
Here is the context :
I am working on a makefile to create a .h at every build, including another makefile that will use this header. I can't edit the second one.
Using a target all depending on my file, it compiles the first time, creating the missing MyHeader.h. The problem is, when I recompile, the header is not regenerated...
My makefile looks like this :
all: myHeader.h
myHeader.h:
scriptToBuildMyHeader.sh
include obscureAndPrivateMakefile.make
I also tried with a .phony target at the beginning. Same result : once created, it won't be regenerated at every build.
PS : I can't call a script before make.
Do some makfile-Masters have any ideas how to deal with that ?
Thanks!
Because myHeader.h has no dependencies, it will never be rebuilt once it exists. You can work around this by creating a dependency from myHeader.h to a phony target, eg:
forcebuild:
# dummy; do nothing and don't create this file
.PHONY: forcebuild
myHeader.h: forcebuild
scriptToBuildMyHeader.sh
This will however slow down your build considerably, as the header (and any source files including it) will need to be rebuilt every time.
The trouble is that because myHeader.h does not depend on anything, it exists and is therefore up to date on the second build. To make sure it is built each time, it has to depend on a non-existent file:
myHeader.h: .FORCE
scriptToBuildMyHeader.sh
.FORCE:
The name '.FORCE' (or, sometimes, FORCE) is used classically.
If you use GNU Make, you could make the 'non-existent' file into a phony target:
.PHONY: .FORCE
The advantage of this is that (GNU) make does not create the file .FORCE even if you run make -t - which would break the automatic rebuild of the header because that rule depends on there not being a file .FORCE that actually exists.
Here's another possible approach:
all: clean foo.txt
clean:
rm foo.txt
foo.txt:
echo > foo.txt
where I'm using echo > foo.txt to simulate creation of your header.
In the event that a Makefile itself is changed, a safe bet would be to consider all targets out of date.
Is there a clever way to add this dependency? Are there any alternatives?
Make sure the object files depend on the makefile:
$(OBJFILES) : Makefile
Where Makefile is the name of the make file.
A safe bet, but a terrible idea. Example: you're using automake and update Makefile.am to add a single source file. The correct response is to compile just the new file and link it in. In your scheme everything would be rebuilt.
Moreover, adding the dependency isn't going to do anything unless you touch the file, something like:
$(SRCS): Makefile
touch $#
This will then trip up editors that use the mtime to detect concurrent modification (emacs is one example).
If you're doing something major, just run make clean all after doing the change.
Since GNU make version 4.3 it is now possible with the use of those two special variable:
.EXTRA_PREREQS
To add new prerequisite to every target
MAKEFILE_LIST
To get the path of the make file
To have every target depend on the current make file:
Put near the top of the file (before any include since it would affect the MAKEFILE_LIST) the following line:
.EXTRA_PREREQS:= $(abspath $(lastword $(MAKEFILE_LIST)))
To have every target depend on the current make file and also the make files which were included
Put the following line at the end of your file:
.EXTRA_PREREQS+=$(foreach mk, ${MAKEFILE_LIST},$(abspath ${mk}))