In this post I’ll explain how a 50 yrs old tool make my life easier.

References:

• Makefile documentation
• Autoconf

Before

Typical day at work

Every day at work I’m running the same set of shell commands for different reasons:

• setting up my development environment
• dumping a database
• generating assets
• downloading logs
• deploy application
• test code
• lint code
• …

I had to learn these command to be efficient.

Starting to develop on an unkown project from a README

When I start developing on an existant project wich I don’t know yet, I start reading the README.md just right after a git pull, and before exploring the app sources folder to know how to get start on this project. The README should help me to answer technical questions like:

• How do I generate assets ?
• How do I install the vendors ?
• How do I generate the fixtures ?
• Are my parameters right ?
• How do I run tests suite ?
• How do I run linters ?

But the each time, right after trying to set up the project, I ask for help to the lead dev who often tells me things like: “Pierre, you read the README and it’s not working ? Ah, yes, it’s because”

• this parameter is not used anymore
• this README is old
• we use webpack instead of bower now

Moreover, some commands have to be run before others. For example, I have to run composer install before accessing any command coming from a library, like for Symfony “php bin/console doctrine:migrations:migrate”. So the order of commands ran matters.

A README is outdated

The problem I faced is that a README is often not maintained. Why ? Because when the developer starts from scratch a project, he spends 10 minutes to describe briefly the project to get a nice overview layout on Github/Gitlab/BitBucket, whatever, but once the first sprint is started, README will never be updated.

How Makefile helps me

A Makefile is always up to date

As a project’s Makefile is used each time I’m working on it, I would easier update it to add/improve a recipe to it and share it with the team because I know each developer on the project is using it, whereas how many developers would read updates on a README file ?

I don’t learn command, I understand them

Learning a lot of shell commands with the corrects options does not make me better at my job, but reading a Makefile to understand them and their relations to each others makes me a better developer on a project.

I don’t have to run the command “foo” before the command “bar”

Makefile does it for me:

bar: foo
    my-awesome-command

There is no magic

I can quickly read a Makefile to understand project stack and dependencies. I don’t fear a Makefile since it’s nothing more than recipes and list of instructions.

Fuck off aliases

I do not want to use any alias. Why ? Because when I speak to people I don’t use abbreviation and I don’t like either people dropping abreviations everywhere. Moreover, aliases definitions are related to your bash profile and not relatives to each project you installed on your machine (aliases options can differ following the context of the project). That’s why I prefer having a Makefile per project instead of an overkill list of aliases in my .bashrc.

I use alias because command names are too long. For example, I prefer typing dc instead of docker-compose.

I would answer: “So why don’t you name all your variable with 2 letters in your code ? It’ shorter too.” To me it’s about the same problem, if you are bored to type the same long name of variable/command, that’s because you should refactor your code or review your configuration.

I undersand the project stack

It’s easier to understand the project stack from a Makefile rather than exploring the src folder. Why ? Because the Makefile does not bother you with the folder architecture of src folders.

Now I’m using Makefile

My problems quoted before are solved. I’m still learning how to write a Makefile and my main concern is to not take me away from Makefile purpose, which is building things following a recipe. Makefile is not a list of aliases.

The blog repo itself contains a Makefile

Some questions I’m still asking to myself:

• Should a project Makefile be personal ? I don’t think so. Aliases should be personal since they are stored in a bash.rc, but a project Makefile is versionned.
• How to manage a Makefile between environements ?
• Does Autoconf would make me even happier ?

The funny thing is

There is no better program than Makefile to build things today, even if Makefile is 50 yrs old. Makefile is installed on linux based systems so you can try it now. I would thanks my admin sys teacher 5 years ago who tought me how to build a java program via a Makefile, because today I’m using this to build symfony projects.