Executing makefile [closed] - c++

Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 9 years ago.
Improve this question
I have a makefile in which I added sources files and header files and linked them. I am 100% sure that this makefile is correct because I asked my professors and TA. However, I do not know how to execute a makefile. I have a main.c file in which I have bunch of print statements.
In my makefile I have :
all: main
I am trying to run this by following commands:
make clean
make main
However, nothing is being printed out, it just complies and thats it but I want a way to run this program, how do i do that?

You need to use the all rule like this ...
make all
... or simply ...
make
This is assuming your makefile is named "Makefile" or "makefile". If it is named something else, you'll need the -f option:
make -f app.mak
Note: I'm using "app.mak" as an example.
If you want to execute your program after making it. You'll have to add another line, such as:
all: main
./main
This is assuming your executable is in the current directory and its named main.

You don't want to execute a makefile; you're doing that by running make. Make builds programs. It doesn't usually run programs that it builds, although it can do so.
In your example above if you want to run the program after make builds it, you just use:
./main
to run it. If you want to create a makefile rule that will run the program, you can add to your makefile something like:
run: main
./main
If you put this at the end of the makefile then you can run make run to build and run the program. If you put it at the beginning of the makefile (before all anyway) then you can type make and it will build and run the program, or type make all or make main and it will just build the program without running it.

Related

Issue with Makefile

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.

How do I compile multi-file C++ programs in all subdirectories?

I have a bunch of C++ programs each in its own sub-directory. Each sub-directory has a single C++ program in several files -- a .h and a .cpp file for each class plus a main .cpp program. I want to compile each program placing the executable in the corresponding sub-directory. (I also want to run each program and redirect its output to a file that is placed in the corresponding sub-directory but if I can get the compilation to work, I shouldn't have a problem figuring out this part.)
I'm using the bash shell on a UNIX system (actually the UNIX emulator Cygwin that runs on top of Windows).
I've managed to find on the web, a short scrip for compiling one-file programs in the current directory but that's as far as I've gotten. That script is as follows.
for f in *.cpp;
do g++ -Wall -O2 "$f" -o "{f/.cpp/}";
done;
I would really appreciate it someone could help me out. I need to do this task on average once every two weeks (more like 8 weeks in a row, then not for 8 weeks, etc.)
Unless you're masochistic, use makefiles instead of shell scripts.
Since (apparently) each executable depends on all the .h and .cpp files in the same directory, the makefiles will be easy to write -- each will have something like:
whatever.exe: x.obj y.obj z.obj
g++ -o whatever.exe x.obj y.obj z.obj
You can also add a target in each to run the resulting executable:
run:
whatever.exe
With that you'll use make run to run the executable.
Then you'll (probably) want a makefile in the root directory that recursively makes the target in each subdirectory, then runs each (as described above).
This has a couple of good points -- primarily that it's actually built for this kind of task, so it actually does it well. Another is that it takes note of the timestamps on the files, so it only rebuilds the executables that actually need it (i.e., where at least one of the files that executable depends on has been modified since the executable itself was built).
Assuming you have a directory all of whose immediate subdirectories are all c++ programs, then use some variation on this...
for D in */; do cd "$D";
# then either call make or call your g++
# with whatever arguments in here
# or nest that script you found online if it seems to
# be doing the trick for you.
cd ../;
done;
That will move in to each directory, do its thing (whatever you want that to be) and then move back out.

Makefile for Linux from Xcode-written C++ program

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

Get the compiler options from the program [duplicate]

This question already has answers here:
Detect GCC compile-time flags of a binary
(4 answers)
Closed 9 years ago.
Is there any macro in c++ (using gcc) to get the compilation options used to build the executable ?
I'm sure I saw something like that in some about dialogs.
any help will be appreciated
PS: while the question in Detect GCC compile-time flags of a binary interests in finding the options activated to compile a program, I'm interesting in finding the exact command line options used to compile my program from within this program source.
Apart from creating the compile string from the
Common Predefined Macros
, which seems hectic. I think there is an easy way to do it. The gcc -V on debian gives back flags used for configuration.
However, my shot would be to get full command in ./configure equivalent step and dump it to some file like config_line.h as a define.
Something like:
./configure:
#!/bin/sh
echo "#define conf_flags \"configured with: "$*"\"" >> config_line.h
#do some configuration steps here
#maybe even compilation itself
Then:
luk32:~/projects/tests$ ./test.sh --with=test
luk32:~/projects/tests$ cat ./config_line.h
#define conf_flags "configured with: --with=test"
You get full config line defined in the external file under a define statement. I think its fairly straight forward and easy to use. And no need for much compiler magic.
It is also worth of noting you can most probably (if not always) create such file(s) right before the actual compilation so they are actually up-to-date and valid during compilation step. Answer in get-the-compiler-options-from-a-compiled-executable would imply the executable already exists, which might be a bummer in some cases.
Note: I gave bash example, but I'm pretty sure you can output similar header file under any half-descent build system, be it make, qmake, cmake, etc. the bash begin the simplest case.
I think most of them have access to the command line they are invoked with, as well as they provide easy way to get actual compile command. For example to provide two literals, one with commands used for make like -j 13 and another g++ ... used for actual compilation step performed by make.
Note2: I know this is not an answer the OP asked, but I guess it serves his purpose in the 1st place.
Because I'm using qmake build system I came across this solution :
I added this line to the end of my pro file :
QMAKE_CXXFLAGS += -DFLAGS=\"$$QMAKE_CXXFLAGS $$QMAKE_CXXFLAGS_RELEASE\"
then retrieved what I want from the FLAGS macro

what do i need to do to make my c++ program run by only entering the name on my unix system [closed]

Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 12 years ago.
Improve this question
Possible Duplicate:
Code won’t run. [not]
I have written and compiled a program and i want to make it so that from shell i can just type programname to make it run instead of going to the directory the the program is in and typing ./ before the program name. If this is possible please let me know.
You must learn the ways of the PATH if you're to come with me to Alderaan.
You should add the directory where your compiled program is to your PATH.
For example if you are inside the /home/jimmy/cpp directory
type (leading $ is the prompt)
PATH=$PATH:`pwd`
$myprog
Read about exporting variables and the bashrc file to make this change permanent. (assuming bash as your shell)
A detailed discussion of why putting . (current directory) in the PATH is a bad idea.
Lets say you're being attacked by an adversary on your machine.
He authors a malicious program, and puts it in a directory, hoping that you'll stumble on it eventually. To increase his chances, he names it something common like mv.
If you have added . to the beginning of your path, and happen to be in the right directory when you type mv onefile twofile... then the local mv (./mv) gets run instead of the mv command we're all used too! This happens because . is in your path, and the local mv will be found before the /usr/bin/mv. Suddenly, your user account or the entire machine may be horribly compromised.
(note: mv might be one of the built-in commands, and immune to this. Not sure... but the principle is solid)
So, you learn the lesson, and now put . at the end of your path, so that all "official" directories will be searched before the local directory.
But the attacker is now on to you! Instead of the program mv, he creates in a program mc, which is a common typo for mv. Again, you intend to type mv onefile twofile, but make a simple typo to mc. Now all the "official" directories are searched, the program mc is not found, and finally it is found in the local directory. Malicious code is run, and again you lose.
The lesson is that your PATH should only cover known-good software, and since your current directory changes frequently, you never know exactly what software is there, and should never run it unless you're very explicit about it with the ./ prefix (eg. > ./IMeanToRunThis)
http://ss64.com/bash/alias.html
e.g.
alias progname=/path/to/program/progname
Personally, I use $HOME/bin as a personal collection point for utilities I wrote but that won't be of use to all users. Otherwise, /usr/local/bin is often the right place for locally written programs that are of use to all users. In any case, I have verified that the latter place was on my path and added $HOME/bin as well.
Unless you really are an installer, it is probably not a good idea to go dropping programs into /bin or /usr/bin despite temptation. That would be the moral equivalent of putting your programs in C:\Windows or C:\Windows\System32. It is effectively never the correct answer.
Learning more about the PATH environment variable and how the shell searches for programs to run is definitely recommended. Also, as pointed out in another comment, just don't add . to your PATH because it will come back to haunt you at some point.
Edit: Incidentally, I do a very similar thing on my Windows boxen. I always create a sibling to C:\Program Files named C:\Programs. In there, I make a folder named bin and add that to the system path. I use C:\programs\bin much like I use $HOME/bin on a *nix box, and put any hand-installed (i.e. no real Windows installer was used) programs or stuff ported from *nix that can't tolerate spaces in its path in there in other folders such as C:\Programs\mingw, C:\programs\MSYS, or C:\programs\cygwin.
Any small utilities primarily used from the command prompt usually end up in C:\programs\bin, but for anything I'm seriously planning to use on more than one PC I generally create a real Windows installer with InnoSetup and let it get installed in C:\Program Files.