Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Makefiles – Best Practices

danyspin97.org

Post reply on HN
Print view View original

41–50 of 127 posts

Re: Makefiles – Best Practices

#41

Post by jgrahamc »

deng wrote: post #31
jgrahamc wrote: post #14

Earlier quoted context omitted.

Yes. It is highly recommended that you read that book (buy it to support the FSF). If you want more I wrote a book on GNU Make ( https://nostarch.com/gnumake ) which takes things further than the GNU Make manual. A large amount of the content of the book came from a sequence of blog posts on GNU Make by me: https://blog.jgc.org/2013/02/updated-list-of-my-gnu-make-art...

Your book is awesome, thanks for writing it! I converted our whole build at $DAYJOB from recursive to non-recursive, and your book helped immensely. It was a lot of work, but in the end it was worth it.

That's very kind. Weirdly, I have never done a conference presentation about GNU make. If I did what would people want to hear about?

Re: Makefiles – Best Practices

#42

Post by htfy96 »

dbcurtis wrote: post #27
brookhaven_dude wrote: post #21

What about using Python (with system calls) to build the project? Much more understandable than Makefiles.

OK, so I am as much of a hard core Pythonista as you will find. But I don't think it makes any sense to build C projects (or many other languages) with Python instead of makefiles. C programmers know make, the makefile idiom has been evolving for 40+ years. A seasoned C programmer is going to look at an idiomatic makefile and find it much more readable than some rando doing some one-off Python script to control a bui…

As a C developer I have to say there exists no idiomatic makefile - configuring header file dependencies with -MMD/auto rebuild targets affected by FLAGS change already makes your Makefile look like magic. As the project grows, eventually you will need some kind of flexibility that makefile cannot do well. In this case, explicit Python scripts become more useful that a bunch of possibly implicit makefile rules.

Re: Makefiles – Best Practices

#43

Post by jgrahamc »

AceJohnny2 wrote: post #29
jgrahamc wrote: post #17

Earlier quoted context omitted.

https://www.cmcrossroads.com/article/tips-and-tricks-automat...

Thanks John, your book is the most-referred to on my office shelf ;) Edit: https://nostarch.com/gnumake (via https://blog.jgc.org/2015/04/the-gnu-make-book-probably-more... )

That'a great. Glad it was helpful. If you have any of your own GNU Make tips and tricks please do blog about them!

Re: Makefiles – Best Practices

#45

Post by jgrahamc »

chubot wrote: post #25
girzel wrote: post #4

I recently decided it was time to get a better understanding of how makefiles work, and after reading a few tutorials, ended up just reading the manual. It's long, but it's very, very well written (a good example of one of the Gnu projects biggest strengths), to the point where just starting at the top and reading gives an almost tutorial-like effect. Just read the manual!

FWIW I also read the GNU Make manual, and based some code for automatic deps off a profoundly ugly example it had. Then later people on HN showed me a better/simpler way to do it. https://news.ycombinator.com/item?id=15060149 https://www.gnu.org/software/make/manual/html_node/Automatic... After reading the manual and writing 3 substantial Makefiles from scratch, I still think Make is ugly and, by modern standards, no…

GNU Make makes it easy to write a makefile that works well for a clean serial build, but has bugs once you add -j or when your repository is in some intermediate state.

So true. I wrote about this and solutions here: https://www.cmcrossroads.com/article/pitfalls-and-benefits-g...

Re: Makefiles – Best Practices

#46

Post by culp »

RHSeeger wrote: post #20
Orphis wrote: post #15

Makefiles, Best Practices: Don't write Makefiles, use a higher level language to describe your goal and some tool to execute it (either directly or through generating a Ninja file). The Make language is the assembly language of build systems. Do you really enjoy writing assembly all the time?

I have yet to find a build system I prefer over Make. I use Maven at work and use a Makefile to run mvn. It lets me easily run a wide variety of commands locally as part of my build.

Any chance you can share that here?

Re: Makefiles – Best Practices

#47

Post by tedmiston »

SamWhited wrote: post #26
tedmiston wrote: post #8

There are so many gotcha with makefiles yet we still use them regularly. I'm considering moving on to something like Taskfile [1], though I haven't tried it yet. [1]: https://taskfile.org/

I decided a long time ago that it's not worth having to install and learn a different tool for every ecosystem just to avoid make's quirks. Yes, make isn't perfect (it can even be quite annoying at times), but neither is everything else so it's worth it to me (from a personal and business perspective) to just make my developers use one thing for all projects, especially since it's already installed (or easily install…

I pretty much went down the same path, though with all of Make's quirks, my generic Makefiles end up being nothing more than an index of commands that instead run bash scripts. But then the problem is shifted into bash's error prone syntax. So then for non-trivial logic, I end up having the bash script call a Python script, especially if dependencies are involved.

It would be nice to have something like EditorConfig for project commands, i.e., my Sublime or your VS Code could parse one common Makefile (or similar) and map its commands to Build, Run, Debug, etc in the UI.

In some sense, I think a different real solution is to Dockerize everything and then just docker build / docker run. Of course this can get complex for some projects, especially where the local setup is different than the production setup, e.g., Docker Compose vs Kubernetes for instance.

Re: Makefiles – Best Practices

#48

Post by self_awareness »

dbcurtis wrote: post #27
brookhaven_dude wrote: post #21

What about using Python (with system calls) to build the project? Much more understandable than Makefiles.

OK, so I am as much of a hard core Pythonista as you will find. But I don't think it makes any sense to build C projects (or many other languages) with Python instead of makefiles. C programmers know make, the makefile idiom has been evolving for 40+ years. A seasoned C programmer is going to look at an idiomatic makefile and find it much more readable than some rando doing some one-off Python script to control a bui…

My experiences with Makefiles are different. I can understand mine up to 3 months after I write them. And if I read someone else's Makefile, it's a binary blob, full of hacks, optimalizations, walkarounds and compatibility quirks between GNU make, BSD make, with sometimes different Makefiles for FreeBSD, Linux, OpenBSD, DOS, and Visual Studio uses its own project file in the win32 directory. It's a mess.

Re: Makefiles – Best Practices

#49

Post by tedmiston »

igor47 wrote: post #13
tedmiston wrote: post #8

There are so many gotcha with makefiles yet we still use them regularly. I'm considering moving on to something like Taskfile [1], though I haven't tried it yet. [1]: https://taskfile.org/

I've been using invoke [1] which has allowed me to give my projects nice UIs while remaining in the primary language. If I were working on Ruby I would stick with Rake, even though I think invoke is better. [1] http://www.pyinvoke.org/

I really like Invoke / Fabric for Python projects, though it feels weird to use in non-Python projects when it comes to dependencies. [Now I have to explain to non-Python people things like virtual envs, pipenv vs pip vs pipsi, pyenv, etc.]

Just curious if you install Invoke individually for each project or keep one global install?

I suppose I could always git exclude the tasks.py Invoke files.

Re: Makefiles – Best Practices

#50

Post by self_awareness »

mruts wrote: post #44
brookhaven_dude wrote: post #21

What about using Python (with system calls) to build the project? Much more understandable than Makefiles.

Is this a joke? Why would anyone ever do that? Except if the only language you know (and ever want to know) is python?

Users of SCons (https://scons.org/), and Waf (https://waf.io/) disagree with your point of view.
Post reply on HN