In a makefile, there is a statement:
include $(PROJECT_CUSTOM_DIR)/project_custom.mak
In some cases, this file will not exist. In those cases, we get the error saying "no such file or directory". However, it appears that an implicit rule (or something), appends the extension .c which then matches one of our standard rules for compiling .c to .o files, and it tries to compile it.
Our default rule for .c files looks like this:
PROJECT_CUSTOM_DIR := .
include $(PROJECT_CUSTOM_DIR)/project_custom.mak
C_EXT ?= c
CXX_EXT ?= cpp
OBJ_EXT ?= o
%.$(OBJ_EXT) : $(C_SRCS)
$(COMPILE_C_COMMAND)
The error from the log is here:
Makefile:10: project_custom.mak: No such file or directory
gcc -c -fvisibility=hidden -O3 -flto -mtune=generic project_custom.mak.c -o project_custom.mak.o
I've read quite a lot trying to determine what is happening here and am stumped. Can anyone explain this behavior?
Also, I am aware of that adding a dash such as -include file.mak suppresses the error about the file not being found. Also, disabling implicit rules is not an option here.
Thanks!
Based on comments, I've now run make with debugging. I found that Make is doing normal/expected evaluation of all files that are included with include(file). The implicit rules for included files is to try to rebuild them if they do not exist. Since this is not what I wanted, I used the following empty explicit rule to override the behavior, and do nothing for all my included files. This was easy in my case because they all share the .mak extension. Here is the rule:
%.mak : ;
Thanks to those who added feedback.
Related
i have been trying to make a correct makefile for a while now but i keep getting the error "make: *** No rule to make target `all'. Stop."
i have one main program: mpasswdsort.c
and the c file wich is used by mpasswdsort, it comes with a header as well:
list.c and list.h
my makefile:
CC=gcc
CFLAGS=-Wall -pedantic -ansi
all: mpasswdsort
server: mpasswdsort.o list.o
$(CC) mpasswdsort.o list.o -o mpasswdsort
mpasswdsort.o: mpasswdsort.cpp
$(CC) $(CFLAGS) mpasswdsort.cpp
list.o: list.cpp
$(CC) $(CFLAGS) list.cpp
clean:
rm -f server client *.o core
I am unsure if its wrong in the makefile or if the makefil isnt supposed to be a .txt file.
The error message you present indicates that make does not see any rule for building target "all". It is exactly the same diagnostic that GNU make emits when there is no makefile at all. Since the makefile contents you present do contain a rule for target "all", I conclude that make is not seeing them.
That may be because the makefile is in a different directory, because its name is different from the ones make tries by default (Makefile or makefile is conventional; GNU's version of make also checks for GNUmakefile), or because an access-control issue prevents make from reading the file. Since you remark
I am unsure if its wrong in the makefile or if the makefil isnt
supposed to be a .txt file.
, the most likely conclusion is that (at least) the filename is wrong. Makefiles are text files, but text file names don't necessarily end with ".txt". In fact, on Linux and other UNIXes, most of them don't. Makefiles shouldn't have such an extension, though, technically, you can use the -f option to tell make the name of the makefile to use.
For me, quite simply, I was initiating the make init command outside of the target directory that I wished to create the makefile. Hope this helps someone.
I'm using a MAC so renaming the "MakeFile" to "Makefile" did the trick for me.
And one more thing, I got this error after fixing the previous one:
Makefile:3: *** missing separator. Stop.
Replacing the four spaces with tabs solved this problem for me! Simply just delete the space before the commands in your "Makefile" and put a tab behind them.
I'm studying how 'make' works and I encountered a little oddity
Suppose I have a folder with only 'helloworld.c' and 'Makefile'
Makefile contains
helloworld: helloworld.o
gcc -o helloworld helloworld.o
The output of 'make' in a bash console is
cc -c -o helloworld.o helloworld.c
gcc -o helloworld helloworld.o
The rule "helloworld" depends on the file "helloworld.o" which is not present, hence make creates it (the first line in the output).
But why?
I would have expected it to fail, in absence of a "helloworld.o:" rule that tells it how to compile said file. Why does it run the first command out of its own will?
Thanks
The reason is implicit rules.
From the GNU Make manual:
Implicit rules tell make how to use customary techniques so that you
do not have to specify them in detail when you want to use them. For
example, there is an implicit rule for C compilation. File names
determine which implicit rules are run. For example, C compilation
typically takes a .c file and makes a .o file. So make applies the
implicit rule for C compilation when it sees this combination of file
name endings.
In other words, make knows how to build helloworld.o from helloworld.c even if you don't specify an appropriate rule.
To get more information on this subject you can follow GNU Make manual, especially section 10, which is devoted to the usage of implicit rules.
I am somewhat of a beginner in C and have a project due where I need to include a makefile to compile my single file program that uses pthreads and semaphores. My makefile looks like:
# Makefile for pizza program
pizza: pizza.o
gcc -lrt -lpthread -g -o pizza pizza.o
pizza.o: pizza.c
gcc -lrt -lpthread -g -c pizza.o pizza.c
and I keep getting:
make: Nothing to be done for 'Makefile'.
I have done several makefiles before and have never gotten this message. I've tried different semantics in the makefile and have only gotten this same message. And yes, the command is tabbed after the target and dependency line.
Using gcc on tcsh. I have read other makefile posts on SO but I wasn't able to use any of the answers to figure it out for my case.
Any help would be greatly appreciated!
The arguments to make are the targets to be built.
You are running make Makefile which is telling make to try to build the Makefile target.
There is no such target in your makefile, make has no built-in rule that applies to that target and the file exists (and is assumed to be up-to-date) which is what that message is telling you.
To run the default target (by default the first target listed) you can just run make (assuming you are using a default name like Makefile for your makefile).
You can also use the -f argument to make to select an alternate makefile name.
So make -f Makefile will in this case (since Makefile is a default searched name) do the same thing as make.
I have written complicated C and C++ makefiles in the past. However, I cannot seem to get my D makefile to work. It throws over a thousand lines of "undefined reference" errors, which look as if Phobos is failing to be linked. How can I fix that?
I am using GNU make and LDC2 on Fedora 19 Linux.
Edit: Compiling and linking directly using LDC2 works correctly. Only when invoked with 'make' is there an error. It seems that make is trying to invoke a separate linker.
Edit 2: Here is my makefile:
# This macro contains the source files
sources := $(wildcard *.d)
binaries := $(sources:%.d=%)
all: $(binaries)
%.o:%.d
ldc2 $< -O5 -check-printf-calls
Deleting the .o fixed it.
I don't know the intricacies of Pattern Rules, but I believe that is where your problem lies.
%.o:%.d
ldc2 $< -O5 -check-printf-calls
You've asked make to convert every .d file into a .o by calling the ldc2 command. However, you aren't requesting ldc2 to build object files, you're asking it to build an executable (I don't know which flag you want dmd/gdc: -c). Though I would have expected compiler errors from this before linker.
By removing the .o I must assume that Make is instead passing all the .d files at once rather than individually.
My makefile defines a link command:
prod_link = $(LINK) $(LINK_FLAGS) -o$(PROD_OUT) $(PROD_OBJS)
where $(PROD_OBJS) is a list of object files of the form:
PROD_OBJS = objfile1.obj objfile2.obj objfile3.obj ... objfileN.obj
Now the makefile itself is at the root of my project directory.
It gets messy to have object and listing files at the root, I'd like to put them in a subfolder.
Building and outputing the obj files to a subfolder works, I'm doing it with suffixes and inference:
.s.obj:
$(ASSEMBLY) $(FLAGS) $*.s -o Objects\$*.obj
The problem is to pass the Objects folder to the link command.
I tried:
prod_link = $(LINK) $(LINK_FLAGS) -o$(PROD_OUT) Objects\$(PROD_OBJS)
but only the first file in the list of object files gets the folder's name.
How can I pass the Objects subfolder to all files of my list $(PROD_OBJS)?
EDIT
I tried also
PROD_OBJS = $(patsubst %.ss,Object\%.obj, $(PROD_SRC))
but got:
makefile(51) : fatal error U1000: syntax error : ')' missing in macro invocation
Stop.
This is quite strange...
nmake is not GNUMake, and is rather rubbish. See the NMAKE Reference for details.
As far as your problem goes (translating 1.o 2.o 3.o into d/1.o d/2/o d/3.o), try
OBJS= 1.o 2.o 3.o
# Looks wierd I know, but basically change ' ' to ' d/'
# (and it's not very robust!)
OBJS_WITH_PREFIX= d/$(OBJS: = d/)
!ERROR [$(OBJS_WITH_PREFIX)]
By the way, your pattern rule is lying to nmake. You say .s.obj:, which says "here is how to convert a .s file into a .obj," but then the commands you give actually create the object in a subfolder. You should have started the pattern rule with .s{Objects\}.obj:. See the docs for more details (Search Paths in Rules).
Very late to the party, but in case anyone else runs into the same problem:
This error
makefile(51) : fatal error U1000: syntax error : ')' missing in macro invocation
Stop.
is caused by the fact that the patsubst syntax doesn't seem to be supported by nmake. You can get around this by using the alternative syntax
$(var:suffix=replacement)
instead of
$(patsubst %suffix,%replacement,$(var))
(this is also valid in gnumake).