What is Reddit's opinion of GNU Make?

From 3.5 billion Reddit comments

I would make a small argument towards C#. C# has awesome things like Linq and [Properties](http://msdn.microsoft.com/en-us/library/x9fsa0sw(v=vs.80\).aspx), as well as lambda functions.

All of those features (clearly Linq won't be called Linq) are slated for Java in the future, but you can use them right now in C# :)

Overall though, the differences are pretty minor. I just find that I get more done in C#. However, if you aren't on Windows, you should really be writing Java. There are also some valuable psuedo-skills as a programmer that you can obtain with Java, like learning how to use make and how to actually invoke a compiler. Usually these things are just a pain in the ass though, to be perfectly honest. I love tooling around on the command line, but it tends to take longer.

A really bad practice amongst economic researchers is writing really long, bloated stata or R files. Often they are not well documented and they often involve a lot of magic and trickery making you scratch your head figuring out why they took certain steps.

The solution I've found is to use makefiles and break up your stata/R files into many small portable pieces.

Make (http://www.gnu.org/software/make/) is basically a way to list out all the steps to get to your result and specify all the dependencies. Some people like to work with drake which is 'make for data': http://blog.factual.com/introducing-drake-a-kind-of-make-for-data

Usually the makefiles will specify how to import the data, clean the data, and process the data.

Try to make your stata files as modular as possible. It's better to have lots of small, clearly defined functions (hopefully self documenting or well documenting ones) then a 1000 line function that tries to do all the steps one after another. This has the added bonus that you can add lots of unit tests and travis to the functions and it will be a lot easier to debug your functions one at at time then trying to write unit tests for a 1000 line behemoth analytics process.

A huge bonus of this approach in addition to reusable and very readable code is that it will be very easy for others to modify and iterate off of your process. good luck.

> Where do I place my libraries and header files?

Wherever you like. You then need to tell the compiler and linker where they are (see GCC tutorials below).

> what is glut32.dll used for?

It's the runtime library that actually contains the GL code.

> All I've done is place is in my system32 folder,

You should probably not do that. The DLL needs to be somewhere that Windows can find it, which means it has to be on the PATH or in your executable's directory.

> Can any of you refer me to a good tutorial or reference document to understand the terminal commands to using MinGW?

I have a series of short tutorials on the GCC command line here.

> How do I make (as in turn the code I wrote in Notepad++ or any other editor into the makefile MSYS uses) into a makefile?

You don't. You write a makefile to turn your code into an executable.

> Can anyone refer or explain me to a tutorial or document that I can learn from how to compose a makefile?

The GNU Make documentation is excellent.

> What the hell is MSYS to MinGW?

MSYS is a bunch of tools like bash, sed, grep etc. which help in the development process.

The error means it's trying to run the program [make](http://en.wikipedia.org/wiki/Make_(software\)#External_links) and can't find it. If you have it installed, you will need to add the path to it to your PATH environment variable. If you don't have it, you will need to download and install it, which you can do from here. You may also have to follow similar instructions to these.

Tell that to GNU folks: http://www.gnu.org/software/make/

> Make is a tool which controls the generation of executables and other non-source files of a program from the program's source files.

> Make gets its knowledge of how to build your program from a file called the makefile, which lists each of the non-source files and how to compute it from other files. When you write a program, you should write a makefile for it, so that it is possible to use Make to build and install the program.

you want to use Implicit Rules, something like

%.pdf: %.tex pdflatex -interaction=batchmode -output-directory $(@D) -job $(@F:.pdf=) $< >/dev/null pdflatex -interaction=batchmode -output-directory $(@D) -job $(@F:.pdf=) $< >/dev/null

and then make asdf.pdf will automatically use that rule if asdf.tex exists. You can declare a specific file's dependencies with an additional rule like:

asdf.pdf: asdf.tex other.pdf other.png etc.blah

and it will compile using the implicit rule after building the deps.

> If I write a nonsense program like: #include <iup.h> int main (void){ return 0; } It compiles fine

Yes, it may compile fine, but it if it tried to do anything it won't link fine. The header file only contains function declarations - the actual code for the functions you use is in a binary library file.

> That said... why?

When you say something like -lcomdlg32 this tells the GCC driver program to link with a library called libcomdlg32.a located in a directory that the compiler knows about. In this case, it's an import library provided by your GCC implementation which refers to the Windows system DLL comdlg32.dll.

> Also static linking? Is this something I'm doing?

Depends what kind of library you link with - in the above case, you are linking with a DLL, and that's true for all Windows system libraries.

> Lastly, make, cmake, tekmake..... what gives?

Never heard of tekmake. Even if you use cmake (which generates makefiles), you should understand vanilla make - the GNU make documentation on it is very good.

This is a bit of a weak spot for Make. Things are easier if you just stick the object files where the sources are (but this is not very nice).

However, there's a trick how you can get the outputs in a different folder without having to write all the rules from scratch. Run make in your output folder, and use vpath directives to tell where the sources are.

NOTE: vpath doesn't work well for searching object files. It's best used to search for source files.

E.g. you want to have your sources under project/src and put the build files in project/build. Add something like this to your Makefile:

SRC_PATH ?= $(dir $(abspath $(firstword $(MAKEFILE_LIST)))) vpath %.c $(SRC_PATH)src

This sets SRC_PATH to be the directory where your Makefile is and then tells make to search for .c files in the src subdirectory.

And then in the project/ directory run make -C build -f ../Makefile.

Well, you will certainly have to learn about make. I would also consider ditching powershell and installing the MSYS toolset, if you haven't already done so. This gives you bash, make and many other POSIX tools as native Windows executables.

OTOH, an IDE is nice too. I recommend Code::Blocks.

> Yet what I've always found myself really wanting, was the ability to write imperative-style functions and macros.

Doesn't the new GNU Make solve that by adding support for Guile (Scheme)? Guile even support dynamic linking of C libraries, so i assume that you could have a Makefile that builds a small library and then calls itself with Guile code that loads that library.

MinGW GCC comes with the "make" utility, or if you didn't install it you can get it from the MinGW site. Before you look at other build tools you should at least get an inkling of how make works - the GCC make manual is a good read.

Yes, you should use an IDE, such as Code::Blocks, which works well with GCC and is available for Linux and Windows. It fully automates the project build process. But you should also learn to use make - it's very widely used, and its a valuable skill. The GNU Make manual is very good.

Have you found anything online? I found this introduction to look reasonable, and there's the official documentation on makefiles.

Hm, I tried typing in the above and it worked well for getting make closer to what it once was! My question for you now is, what does the above actually do?

I went to the GNU manual for make to see if I could try rewriting it myself which then seemed to be a rabbit whole much deeper than I was expecting.

Here's the manual if anyone else is curious along the way: http://www.gnu.org/software/make/manual/make.html#Overview

Nice idea, but the format confuses me. Why are there so many "Intro" headings? Also, why do you touch everything?
EDIT: okay, so this is a summary of http://www.gnu.org/software/make/manual/make.html#Options-Summary

Aah, well in that case I'd probably point you at gnu autoconf. In *nix world, you'll get very used to:

$ ./configure $ make $ make install

Note that autoconf isn't the only build system out there. There are others, but definitely spend the time to learn autoconf. Gnu make is also pre-requisite knowledge. My advice is get good at compiling from the command line.

Fixing the syntax means breaking backward compatibility. And that won't be acceptable to the users. GNU Make introduced a backward incompatible change of a minor thing that was never documented in 3.82 and it broke some older makefiles (including Linux kernel ones). Which is why Debian and other distros are still shipping 3.81. Although GNU Make 4.0 was released, which includes GNU Guile support, and thus kinda provides an improved syntax.

1. https://savannah.gnu.org/bugs/index.php?33034
2. http://www.gnu.org/software/make/manual/make.html#Guile-Integration

It says that if you want to turn a .cpp file into a .o (object code) file, apply the following command. For more details see the (very good) GNU Make manual.

Thanks! For future people who find this thread, here is what I did with windows 7:

1). I downloaded love.

2). I downloaded and installed this program to get the make.exe

3). Control panel -> System and Security -> System -> Advanced System Settings -> Environment Variables. Then, choose the path variable, add ; at the end, add the path to the directory that make.exe is in. While you're at it, add the paths to your zip.exe and unzip.exe too.

4). Go to the hawkthorne-journey directory, make sure there isn't a folder called "-p" or "build," command prompt "make," and it should build. The hawkthorne.love file will be in the new build directory.

I haven't looked at the text editors yet. I'll look at them tomorrow. Thanks for your help!

I've heard good things about CMake before, but I'm having a hard time finding information on it. Everything I know about make came from here, and a few Googles. I haven't found an equivalent resource for CMake.

Given that you have compiled VLC from source, I image that you must at least know how to "$./configure --prefix="/usr/local" && make && make install". My suggestion for where to go from here is to learn what a Makefile actually does. How the Makefile directives define how make will use gcc or g++ typically to build the source .c .cpp files into executable object files. This also is where you can optimize the build for you specific architecture with CFLAGS or CXXFLAGS (e.g. "-march="pentium" -O2"). Here is the documentation for make, although keep in mind that you may not see much difference in performance between an application that has been optimized for you architecture unless other dependencies have also been recompiled/optimized. Beyond that, I would suggest taking a look a the PKGBUILD documentation for Arch Linux here and here for creating an installable/redistributable package for your distribution (this will make installing/uninstalling much easier).