Live data from Hacker News

Time for Makefiles to Make a Comeback

medium.com

11–20 of 116 posts

Re: Time for Makefiles to Make a Comeback

#11
post #6

Earlier quoted context omitted.

The data model of makefiles is perfect for watching and rebuilding. All you need to add is something that monitors the source files for any changes and runs 'make'.

That sounds like a great idea. Does anything like that exist already?

Easy enough (assuming $SRC is your list of source files and 'all' is top level target) 'make watch' could do this

   watch:
        while ! inotifywait -e modify $(SRC) ; do time -p make all; done

Re: Time for Makefiles to Make a Comeback

#13

I'm confused So its agreeable that the building pipeline of NPM calling some packer does replace any-other-language calling any-other-packer, but what is the point in replacing the role of `npm build`, with a makefile that just calls what npm would of called anyways? replacing make with npm with make-calling-npm?

I wrote a bit about an approach I'm using, A Touch Of Make (ATOM), which helps provide better developer UX across teams - particularly ones working on microservices.

https://www.alexhudson.com/2017/04/26/articulating-atom-appr...

You're right, replacing "npm build" with "make build" doesn't win you anything. But that's only true on the small scale. In a service world, there are lots of projects, each with different requirements. Some will have front-end, some won't. Others will require a totally different build process. There will probably be different languages involved.

Using make, you can standardise a lot of this. If you set up a coding standard that after you clone a repo, "make dep" should grab anything the project requires, then developers don't initially need to know whether that's calling out to npm or composer or pip or whatever - it's just "working".

This is a much bigger win when you have a number of projects. The process is standardised, so developers know it's only a two or three step build (or whatever you've setup). They know how to do it, and when they need to look under the covers, they can see how it works, and this knowledge is transferable from one project to another because Make is universal.

I don't advocate doing big Makefiles - that's why I call this approach ATOM; only use a touch of Make. But used judiciously, it smooths out projects very nicely. Not everyone needs that, though.

Re: Time for Makefiles to Make a Comeback

#14
post #11
post #6

Earlier quoted context omitted.

That sounds like a great idea. Does anything like that exist already?

Easy enough (assuming $SRC is your list of source files and 'all' is top level target) 'make watch' could do this watch: while ! inotifywait -e modify $(SRC) ; do time -p make all; done

If you care for it, fswatch is cross-platform:

https://github.com/emcrisostomo/fswatch

Re: Time for Makefiles to Make a Comeback

#15
post #3

I used to be big fan of using Makefile for web development, but have since changed my mind, because make is not very good fit for watch-mode incremental building.

Interestingly enough, I tried using Makefiles for a web project yesterday, and it was a success.

    SOURCES = index.pug layout.pug style.styl main.coffee privacy.md
    OBJECTS = index.html style.css main.js privacy.html

    all: $(OBJECTS)

    watch:
    	http-server &
    	while true; do \
    		$(MAKE); \
    		inotifywait -qq $(SOURCES); \
    	done

    %.html: %.pug
    	pug -P $^

    %.css: %.styl
    	stylus $^

    %.js: %.coffee
    	coffee -c $^

    %.html: %.md
    	markdown $^ > $@

    clean:
    	rm -rfv $(OBJECTS)
This could be extended to produce an out-of-source build by using `-o "$(PUBLIC)"` on the command line generators, but I didn't need it for this project.

Re: Time for Makefiles to Make a Comeback

#17

I'm confused So its agreeable that the building pipeline of NPM calling some packer does replace any-other-language calling any-other-packer, but what is the point in replacing the role of `npm build`, with a makefile that just calls what npm would of called anyways? replacing make with npm with make-calling-npm?

I wrote a bit about an approach I'm using, A Touch Of Make (ATOM), which helps provide better developer UX across teams - particularly ones working on microservices. https://www.alexhudson.com/2017/04/26/articulating-atom-appr... You're right, replacing "npm build" with "make build" doesn't win you anything. But that's only true on the small scale. In a service world, there are lots of projects, each with different r…

>Using make, you can standardise a lot of this. If you set up a coding standard that after you clone a repo, "make dep" should grab anything the project requires, then developers don't initially need to know whether that's calling out to npm or composer or pip or whatever - it's just "working".

In my experience you will end up with a dozen coding "standards" and project structures. Especially in C and C++ where header dependencies have to be generated by the compiler even the most basic makefile will take you at least an hour to create if you already have experience in making makefiles.

Re: Time for Makefiles to Make a Comeback

#18
post #12

Friends don't let friends write recursive makefiles.

Friends don't let friends write Makefiles at all. The author does not appear to be familiar with them, except for the trivial examples in this post.

Every folder gets its own little makefile. Calling those recursive shouldnt result in trouble?

Re: Time for Makefiles to Make a Comeback

#19

Earlier quoted context omitted.

I wrote a bit about an approach I'm using, A Touch Of Make (ATOM), which helps provide better developer UX across teams - particularly ones working on microservices. https://www.alexhudson.com/2017/04/26/articulating-atom-appr... You're right, replacing "npm build" with "make build" doesn't win you anything. But that's only true on the small scale. In a service world, there are lots of projects, each with different r…

>Using make, you can standardise a lot of this. If you set up a coding standard that after you clone a repo, "make dep" should grab anything the project requires, then developers don't initially need to know whether that's calling out to npm or composer or pip or whatever - it's just "working". In my experience you will end up with a dozen coding "standards" and project structures. Especially in C and C++ where heade…

Comes down to how you enforce it. To be clear, I'm not talking about mediating the build in Make unless that's the best tool for the job. On a C project I would use cmake, but within this system I'd run it out of a Makefile at a top level, so the person pulling it can just run 'make build'.

The point is to have a known starting place, so that when you pull down a new project you don't have to spend ages reading about how it works.

Even if you can't grab the deps automatically, doing 'make build' and it saying "Hey, you don't have cmake and a bunch of other things you need, but go look at http://whatever.. to set yourself up" is a much better experience.

Re: Time for Makefiles to Make a Comeback

#20
post #15
post #3

I used to be big fan of using Makefile for web development, but have since changed my mind, because make is not very good fit for watch-mode incremental building.

Interestingly enough, I tried using Makefiles for a web project yesterday, and it was a success. SOURCES = index.pug layout.pug style.styl main.coffee privacy.md OBJECTS = index.html style.css main.js privacy.html all: $(OBJECTS) watch: http-server & while true; do \ $(MAKE); \ inotifywait -qq $(SOURCES); \ done %.html: %.pug pug -P $^ %.css: %.styl stylus $^ %.js: %.coffee coffee -c $^ %.html: %.md markdown $^ > $@…

Do you know about the ; style for rules that have only one line of commands? It helps reduce the number of tabs.

    %.html: %.pug ; pug -P $^
I find it super useful for compact Makefiles:

    %.html: %.pug    ; pug -P $^
    %.css:  %.styl   ; stylus $^
    %.js:   %.coffee ; coffee -c $^
    %.html: %.md     ; markdown $^ > $@
    clean: ; rm -rfv $(OBJECTS)
Also, worth making clean .PHONY since it's not a file.
Post reply on HN