I have to submit a makefile for a project and I can't get it to work. I am trying to use the appropriate c++ 11 standard, execute project2,out, and run the cpp files in my src, but I keep getting the error "Nothing to be done for 'Makefile'."
#specify std=c++11 in your makefile
CXXFLAGS += -std=c++11
#Your executable should be named project2.out
main: g++ -o project2.out src/*.cpp
clean: del *.o
When asking questions please always cut and paste the exact command you typed and the exact output you got, properly formatted for SO (if you get a lot of output trim it down to the relevant parts which includes the command make invoked and at least the first few (not last!!) errors you get).
In this case, if you'd shown us what command you were running I'll bet it's this:
make Makefile
that's wrong. The arguments to make are not the makefile to use: they're the target you want to update. Here you've asked make to update your Makefile, but it already exists so make says "nothing to do".
Just run:
make
to build the default target, or make clean to build the clean target.
Once you get past this, you can begin to work on why your makefile may or may not work.
Related
I remember doing this in my advanced C++ class, but it's been a couple years and I forgot.
I want to make a sort of simple re-usable makefile where I just type "make programName" and it compiles programName.cpp into programName.exe.
I've looked for this for a couple hours, but haven't found what I need. I know this will get marked as duplicate, but at least point me to what I need.
Make has a built-in variable called $(MAKECMDGOALS), which contains all targets specified as command line parameters.
You can use it to generate recipes, like so:
# Stop if 0 or 2+ targets were specified.
$(if $(filter-out 1,$(words $(MAKECMDGOALS))),$(error Expected one target))
name := $(MAKECMDGOALS)
$(name).exe: $(name).cpp
g++ $^ -o $#
Adding a way to customize compiler executable and flags is left as an exercise to the reader. As well as conditionally removing .exe from the target name when building on Linux.
Why do you want your output to be suffixed with .exe? That's a Windows convention that is not followed on POSIX systems like Linux.
If you don't want that you don't even need a makefile at all. You can type make programName with no makefile and if you have a file programName.c, it will be built into an executable programName via make's built-in rules.
I've got a source base in C using autoconf/automake, which now should be compiled using a C++ Compiler.
So I've renamed all files from .c to .cpp and changed all makefiles accordingly. However I get the following error (e.g.):
make[3]: *** No rule to make target 'tmsConfigFiles.c', needed by 'tmsConfigFiles.o'. Stop.
The Makefile basically consists of
bin_PROGRAMS = configparser
configparser_SOURCES = tmsConfigFiles.cpp tmsMoreFiles.cpp tmsEvenMoreFiles.cpp
AM_CXXFLAGS = -I .. -DSOME_DEFINE -Wall -Wextra -etc
This works for the overwhelming parts of the source code (some of which were cpp from start) but for some files the error message above appears. Did try to clean and autoreconf -is etc. to no avail.
The same revision works on Centos 6, fails sometimes on Centos 7, failes always on my Arch box.
Anyone had a similar bug in autotools or knows a workaround?
The obvious thing that I can think of is that you have not re-executed automake (or more properly autoreconf) after changing Makefile.am, and for whatever reason (there are more than a few ways for that to happen) you don't have maintaner-mode enabled.
This is, though, assuming you are actually editing Makefile.am to begin with. If you actually edited Makefile, then it's the opposite problem, automake is doing the right thing and ignoring altogether your changes by re-generating the file that should not be edited.
git clean -fx did not remove .deps directories.
Removing them manually solved the issue.
I've written a simple c++ program on Xcode, all contained within ONE FILE called huffmanGenerator.cpp. The program reads input from a file on the user's computer, and writes output to a file saved to their computer.
The instructor has asked us to create a makefile so that our programs compile and run with g++ OR gcc in Linux; however she never showed us how to do so, and when the class asked for help, her answer was we could figure it out.
I found many links online, but they're all very confusing as this is all new to me, and most of them fail to answer even the most basic questions like what kind of file should the makefile be? Is it a .txt? Should I just save one in word?
Please help do what the instructor won't, enlighten me. Thanks!
what kind of file should the makefile be?
It should be a plaintext file called Makefile or makefile. The reason the name matters is because when you run the make command, it looks for a file with this name by default for directions on how to compile your code. You can also name it whatever you want as long as you specify the name when you run it (make -f filename).
Is it a .txt?
No, it has no extension. Extensions don't mean that much in *nix.
Should I just save one in word? (Assume you mean Microsoft Word.)
No, definitely not. Whitespace (tabs/spaces/new lines) have meaning in these files, so you should use an editor that won't add formatting to the file. Something like pico/vi/etc.
Here is an example of a makefile, that I think does what you are asking.
# You can change your compiler to gcc / g++ here.
CC=g++
# Add whatever flags you want to use here.
CFLAGS=-c -Wall
all:
$(CC) $(CFLAGS) huffmanGenerator.cpp -o huffmanGenerator
#Use something like this to run `make clean` which deletes your object files, so you can do a fresh compile.
#clean:
# rm -rf *o huffmanGenerator
As a side note, you would be served well not to blame your professor for not spelling out everything for you. When you graduate, you will often be given tasks that have no other directions than a set of requirements and a deadline. You will need to figure it out. You could have easily made this make file by visiting http://mrbook.org/tutorials/make/ (search google for 'makefile tutorial').
The makefile should be called Makefile. It is just a text file.
You need a text editor. There are many to choose from, vim, emacs, nano, pico, ..., etc.
Open a command line and run, say
$ pico Makefile
Then you would enter the contents of the Makefile
all:
g++ -o huffmanGenerator huffmanGenerator.cpp
Save and exit and run make
$ make
I'm using a tool chain where I do not know the names of all of the intermediate files.
E.g. I know that I start out with a foo.s, and go through several steps to get a foo.XXXX.sym and a foo.XXXX.hex, buried way down deep. And then running other tools on foo.XXXX.hex and foo.XXXX.sym, I eventually end up with something like final.results.
But, the trouble is that I don't know what the XXXX is. It is derived from some other parameters, but may be significantly transformed away from them.
Now, after running the tool/steps that generate foo.XXXX.{sym,hex}, I now typically scan the overall result directory looking for foo.*.{sym,hex}. I.e. I have code that can recognize the intermediate outputs, I just don't know exactly what the names will be.
I typically use make or scons - actually, I prefer scons, but my team highly prefers make. I'm open to other build tools.
What I want to do is be able to say (1) "make final.results", or "scons final.results", (2) and have it scan over the partial tree; (3) figure out that, while it does not know the full path, it definitely knows that it has to run the first step, (4) after that first step, look for and find the foo.XXX.* files; (5) and plug those into the dependency tree.
I.e. I want to finish building the dependency tree after the build has already started.
A friend got frustrated enough with scons' limitations in this area that he wrote his own build tool. Unfortunately it is proprietary.
I guess that I can create a first build graph, say in make with many .PHONY targets, and then after I get through the first step, generate a new makefile with the new names, and have the first make invoke the newly generated second makefile. Seems clumsy. Is there any more elegant way?
GNU make has an "auto-rexec" feature that you might be able to make use of. See How Makefiles Are Remade
After make finishes reading all the makefiles (both the ones found automatically and/or on the command line, as well as all included makefiles), it will try to rebuild all its makefiles (using the rules it knows about). If any of those makefiles are automatically rebuilt, then make will re-exec itself so it can re-read the newest versions of the makefiles/included files, and starts over (including re-trying to build all the makefiles).
It seems to me that you should be able to do something with this. You can write in your main makefile and "-include foo.sym.mk" for example, and then have a rule that builds "foo.sym.mk" by invoking the tool on foo.s, then running your "recognized the next step" code and generate a "foo.sym.mk" file which defines a rule for the intermediate output that got created. Something like (due to lack of specificity in your question I can't give true examples you understand):
SRCS = foo.s bar.s baz.s
-include $(patsubst %.s,%.sym.mk,$(SRCS))
%.sym.mk: %.s
<compile> '$<'
<recognize output and generate makefile> > '$#'
Now when make runs it will see that foo.sym.mk is out of date (if it is) using normal algorithms and it will rebuild foo.sym.mk, which as a "side effect" causes the foo.s file to be compiled.
And of course, the "foo.sym.mk" file can include ANOTHER file, which can recognize the next step, if necessary.
I'm not saying this will be trivial but it seems do-able based on your description.
Make constructs the graph before running any rule, so there won't be a perfect answer. Here are some reasonably clean solutions.
1) use PHONY intermediates and wildcards in the commands. (You can't use Make wildcards because make expands them before running rules.)
final.results: middle
# build $# using $(shell ls foo.*.sym) and $(shell ls foo.*.hex)
.PHONY: middle
middle: foo.s
# build foo.XXXX.sym and foo.XXXX.hex from $<
2) Use recursive Make (which is not as bad as people say, and sometimes very useful.)
SYM = $(wildcard foo.*.sym)
HEX = $(wildcard foo.*.hex)
# Note that this is is the one you should "Make".
# I've put it first so it'll be the default.
.PHONY: first-step
first-step: foo.s
# build foo.XXXX.sym and foo.XXXX.hex from $<
#$(MAKE) -s final.results
final.results:
# build $# using $(SYM) and $(HEX)
3) Similar to 2, but have a rule for the makefile which will cause Make to run a second time.
SYM = $(wildcard foo.*.sym)
HEX = $(wildcard foo.*.hex)
final.results:
# build $# using $(SYM) and $(HEX)
Makefile: foo.s
# build foo.XXXX.sym and foo.XXXX.hex from $<
#touch $#
I'm new to compiling C/C++ with the aid of make. I downloaded an open source project and noticed that there is in the make file CXXSources and CXXObjects. I think I understand roughly what the make file is doing with them but...
I don't have any of the source files listed under CXXSources. Are these like dependences I'm supposed to know how to find? Is there any custom as to what CXXSource is versus just Source?
Added link to project: http://www.fim.uni-passau.de/en/fim/faculty/chairs/theoretische-informatik/projects.html
More specifically, the GML parser, eg. http://www.fim.uni-passau.de/fileadmin/files/lehrstuhl/brandenburg/projekte/gml/gml-parser.tar.gz
It seems to be getting stuck on the line:
gml_to_graph : $(CXXOBJECTS) gml_scanner.o gml_parser.o
$(CXX) -o gml_to_graph_demo $(CXXOBJECTS) gml_parser.o gml_scanner.o -L$(LEDADIR)/lib -lG -lL -lm
The $CXXObjects is defined by
CXXSOURCES = gml_to_graph.cc gml_to_graph_demo.cc
CXXOBJECTS = $(CXXSOURCES:.cc=.o)
So I need gml_to_graph.cc, it seems. Or maybe I'm wrong?
Usually, the variables are set before the point where you see them. This could be
(a) via the environment
(b) before including the quoted makefile
(c) in the quoted makefile, but preceding the location quoted
To see (verbosely) what GNU make takes into account, do:
make -Bn
(it will show everything that _would get executed)
Even more verbose:
make -p all
It will show you all the internal variable expansions.
If you post a link or more information, we will be able to come up with less generic (and hence possibly less confusing) answers