Goal
When I run the command:
gcc -ggdb -std=c99 -Wall -Werror hello.c -lcs50 -o test.exe from the root directory
I am able to build the test.exe file and when I run test.exe all is well (thanks to this post by Manohar Reddy Poreddy)
However all of those flags are a little bit cumbersome and I think it would great to condense them into a 'make' command or similar. How would I do this on windows?
Context
GCC, G++ and GDB all seem to be correctly linked (I used chocolatey which paths everything automatically)
Okay so I found what I was looking for.
I hope this answer can help others. Turns out the utility is called 'make' (no surprises). In your directory you essentially create a 'makefile' where you can include your command line arguments which saves on repeated typing in the command line for each compile.
Here is an excellent response on how to install 'make' for windows and was perfect for my use case as a Chocolatey user.
I also found this resource which helps newcomers begin to get their head round GCC which I highly recommend if you're coming into this like I was and felt completely out of your depth.
I installed gcc on windows via msys32. On powershell and on command prompt it executes properly.
The only strange thing: which gcc yields /usr/bin/gcc, yes with unix slashes.
In real world it is installed in ~/AppData/Roaming/msys32/usr/bin so the msys path is cut off.
In git bash gcc yields no command not found but just nothing.
Also which gcc yields /c/Users/ere/AppData/Roaming/msys32/usr/bin/gcc.
So the problem is specific for git bash, right? But I cannot interpret the outcome.
Any ideas?
I have:
fileMainProgram.cpp
fileClassImplementation.cpp
fileClass.h
makefile
in a directory.
Ran cmd and typed
g++ -make -f makefile
got this message after tinkering with it for a while (change file name/extension, tried without -f, used gcc instead of g++, etc)
C:\miscprograms\Dropbox\box\Dropbox\c++\etextbook\e12\progec12\pe1c12romanNumeral>g++ -make -f makefile
c:/mingw/bin/../lib/gcc/mingw32/4.6.2/../../../../mingw32/bin/ld.exe:makefile.tx
t: file format not recognized; treating as linker script
c:/mingw/bin/../lib/gcc/mingw32/4.6.2/../../../../mingw32/bin/ld.exe:makefile.tx
t:1: syntax error
collect2: ld returned 1 exit status
This is the makefile, (tried to delete the lines inbetween targets and actions, tried using automatic variables, etc,
I tried to compile the program as
g++ -c fileClassImplementation.cpp
then
g++ fileClassImplementation.o fileMain.cpp
to get an executable and it works fine.
all: a
a: romanNumeralMain.o romanNumeralImp.o
[1 tab]g++ romanNumeralMain.o romanNumeralImp.o -o a
romanNumeralMain.o: romanNumeralMain.cpp
g++ -c romanNumeralMain.cpp
romanNumeralImp.o: romanNumeralImp.cpp
g++ -c romanNumeralImp.cpp
clean:
rm romanNumeralImp.o romanNumeralMain.o a
Ran the whole thing on C4droid for my samsung phone and worked fine as is.
Doesn not work on my Windows7 laptop.
What you appear to have is a GNU Makefile, suitable for running GNU Make. Windows doesn't come with GNU Make, so you'll need to download it yourself.
It appears you've already downloaded MingW, try running the mingw32-make command to execute your makefile.
gcc (or other compilers) often generate huge text output and it's very difficult to see where the error is or miss warnings. I've done some search but havn't found a clean simple solution to color code the compiler output (so for instance warnings are yellow, errors are red, etc...)
Gcc 4.9 seems to have added this feature via the -fdiagnostics-color flag:
here's an alternative if you are looking for something very simple:
#!/bin/bash -e
make ${#} 2>&1 | perl -wln -M'Term::ANSIColor' -e '
m/Building|gcc|g++|\bCC\b|\bcc\b/ and print "\e[1;32m", "$_", "\e[0m"
or
m/Error/i and print "\e[1;91m", "$_", "\e[0m"
or
m/Warning/i and print "\e[1;93m", "$_", "\e[0m"
or
m/Linking|\.a\b/ and print "\e[1;36m", "$_", "\e[0m"
or
print; '
Just alias your make to this script and make sure it's executable...
Debian and Ubuntu gives the colorgcc package for that purpose.
And I usually run gcc (and make) thru emacs with M-x compile then the messages are colorized.
addenda
GCC 4.9 has a native colorization facility and GCC 6 - released end of April 2016 - (and probably GCC 5 too) is enabling it by default (when stdout is a terminal).
Ok, I'll just leave a notice about my own (python based) tool also :)
It is called Pluggable Output Processor and designed not only to colorize output of one particular program. Here is sample GCC output before:
After:
See colorgcc, a perl script that coulours the gcc output.
How to install and use colorgcc to colorize your gcc compiler output:
At least 3 answers here so far mention colorgcc, but NONE OF THEM EXPLAIN HOW TO INSTALL IT! (And it's not obvious). So, here's how to install the latest version in Ubuntu!
Go here and click "Clone or download" --> "Download Zip". I saved it into "~/Downloads/Install_Files"
Navigate to it in your file browser and right click it and go to "Extract Here." I now have a directory called "~/Downloads/Install_Files/colorgcc-master".
Copy the "colorgcc.pl" script to "/usr/bin/colorgcc" to "install" it (be sure to use the correct directory according to where you extracted it above): sudo cp ~/Downloads/Install_Files/colorgcc-master/colorgcc.pl /usr/bin/colorgcc
Make it executable: sudo chmod +x /usr/bin/colorgcc
Make the "~/bin" directory if it does not yet exist: mkdir ~/bin
*Make symbolic links that point to "/usr/bin/colorgcc" so that whenever you call gcc or g++ it automatically calls colorgcc instead:
ln -s /usr/bin/colorgcc ~/bin/g++
ln -s /usr/bin/colorgcc ~/bin/gcc
(if you ever want to uninstall colorgcc for some reason just delete these symbolic links "~/bin/g++" and "~/bin/gcc", and the Perl script: "/usr/bin/colorgcc" and you're done)
Done!
Here is a sample g++ output now when I call g++ -Wall -std=c++11 time_until_overflow_2.cpp -o time_until_overflow_2:
*Note: making these symbolic links in "~/bin" only works if "~/bin" is in your PATH variable in a location before the folder where the actual gcc and g++ executables are located. To ensure you have "~/bin" in your path you can view the PATH variable contents with: echo $PATH. If you don't see "/home/YOUR_USERNAME/bin" at the beginning of your path, add it with: export PATH=~/bin:$PATH.
References:
See here for more info. and for where I originally learned most of these steps: https://imranfanaswala.wordpress.com/2009/02/02/setting-up-colorgcc/. Thanks Imran Fanaswala!
~GS
you can use GilCC which is a Ruby tool that will convert GCC output to color in real-time. Right now you have two choices: Perl script (colorGCC) or GilCC and if you already work with Ruby you will like GilCC.
Unique to GilCC; GilCC has warning and errors counters and also shows compile time, very handy when you are trying to improve things. Because it is in Ruby it is cross platform. It is flexible and you can add more gems to customize it anyway you want.
The link to the download page is here.
https://github.com/gilmotta/GilCC
Although GCC 4.9 has -fdiagnostics-color option to enable colored outputs to terminals, I have created a tiny tool called 'crror' to get colorized compiler output.
It supports outputs from make as well. I can add colorize patterns for other tools if anyone requires.
if I understand the gcc manuals right than the option -print-prog-name should print the name of the program used.
But it seems that this option only echoes the given argument
Examples:
gcc -print-prog-name=ld
--> ld
gcc -print-prog-name=xxxsome-funny-name
--> xxxsome-funny-name
Is this the expected behaviour? I think it should print something like
gcc -print-prog-name=ld
--> /usr/bin/ld
gcc -print-prog-name=xxxsome-funny-name
--> unknown program
EDIT: testing on Debian Lenny 64bit with gcc v4.2.4
Meanwhile I found another reason for the behaviour of
gcc -print-prog-name=ld
The ld command is not invoked directly by gcc.
gcc invokes collect. And it is collect which in turn invokes ld.
I think the -print-prog-name option only applies to a small set of tools that GCC
uses internally. For example,
$ gcc -print-prog-name=cc1
/usr/libexec/gcc/x86_64-redhat-linux/3.4.5/cc1
$ ls -L /usr/libexec/gcc/x86_64-redhat-linux/3.4.5/
cc1 cc1plus collect2 f771 jc1 jvgenmain
$ gcc -print-prog-name=f771
/usr/libexec/gcc/x86_64-redhat-linux/3.4.5/f771
So gcc -print-prog-name is aware of the tools that live in that directory. But:
$ gcc -print-prog-name=ld
ld
My guess is that if gcc -print-prog-name returns an absolute path, it's configured
to use that version of the program, no matter what's on your $PATH -- otherwise
it just echoes back what you gave it without resolving it to an absolute pathname.