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

Make for hipsters

mattandre.ws

Post reply on HN
Print view View original

181–190 of 200 posts

Re: Make for hipsters

#181

Post by JdeBP »

efaref wrote: post #109
leni536 wrote: post #70

Earlier quoted context omitted.

Is this always correct? The %.d files don't depend explicitly on the %.c files so they aren't rebuilt every time at the beginning of the make run, so old dependencies are included after a change in header dependencies. I'm still trying to construct an example where such a makefile breaks though.

The only case it becomes problematic is if you delete a header file, as make won't know how to remake it and won't recompile the C file (removing the dependency) until it has done so. There are two options to resolve this: Also specify -MP on the GCC command line, which causes GCC to emit an empty rule for all the header files, like this: foo.o: foo.c foo.h bar.h foo.h: bar.h: Alternatively, you can write a generic e…

Neither make nor any of its alternatives or improvements get header files completely right. This is because compilers simply do not emit all of the information. A build tool not only has to know about the header files found, to monitor them for changes, but also has to know about the places where header files were not found, to monitor for files suddenly appearing there. I wrote a C++ preprocessor that would spit out both sets of information, for use with redo, but I've never published it. Without this information things can end up not being re-built correctly in a number of cases that one can encounter in practice.

Re: Make for hipsters

#182

Post by jbergens »

majewsky wrote: post #68
jbergens wrote: post #52

Another way is using npm-install-changed for the "npm install" problem and fix everything else with other npm scripts like npm-run-all. Use make if you like it but if everything else is npm you can solve most problems using "npm run" and npm scripts. https://github.com/oNaiPs/npm-install-changed http://blog.keithcirkel.co.uk/how-to-use-npm-as-a-build-tool... [edit: formatting]

Supplying even a trivial Makefile is advantageous if your target audience knows it. They'll see a Makefile and just do `make && make check && make install` without needing to browse your README. For example, Debian's packaging process is heavily optimized towards Makefiles that supply the standard targets, and you can reduce a lot of friction for packagers if you supply a wellbehaving Makefile with your program. (Eve…

yes it is good to adapt to your target audience. If that is linux users a makefile might be the best. For a lot of other users like javascript web developers npm might be better. For end users on windows an msi or exe installation file is probably best. Makefiles are unusual on windows which makes them a somewhat bad solution even for developers on windows machines. If you want to create system that works on multiple platforms there are probably better ways. At least make sure to not use some *nix-only syntax in the makefile or calling grep or awk.

Re: Make for hipsters

#183

Post by JdeBP »

jbergens wrote: post #182
majewsky wrote: post #68

Earlier quoted context omitted.

Supplying even a trivial Makefile is advantageous if your target audience knows it. They'll see a Makefile and just do `make && make check && make install` without needing to browse your README. For example, Debian's packaging process is heavily optimized towards Makefiles that supply the standard targets, and you can reduce a lot of friction for packagers if you supply a wellbehaving Makefile with your program. (Eve…

yes it is good to adapt to your target audience. If that is linux users a makefile might be the best. For a lot of other users like javascript web developers npm might be better. For end users on windows an msi or exe installation file is probably best. Makefiles are unusual on windows which makes them a somewhat bad solution even for developers on windows machines. If you want to create system that works on multiple…

Makefiles are only considered unusual on Windows if one ignores decades of .MAK files. (-:

Re: Make for hipsters

#184

Post by JdeBP »

jacquesm wrote: post #23
nkuttler wrote: post #15

Make is a great tool for automating simple things, but if you use a programming language you should probably use native automation tools for common tasks. If you have any non-trivial logic or want to enable code-reuse make doesn't seem like the right choice either.

I hate this. Every programming language that bolts on its own build environment. Make is language agnostic and that's a huge benefit, it means you have to learn about just one build tool and its peculiarities and that will allow you to build many different projects in different languages. All these languages with their half-baked build tools that won't accept that they may have to play nice with other languages and t…

... which is of course addressing make as merely a "build tool" for "projects".

One of the normal conventions for Daniel J. Bernstein's tinydns is to use make. No "projects" or "builds" are involved. The goal is not to create a program. Rather, make is used to ensure that the binary form of the DNS database is re-built whenever the system administrator has edited the text form. The administrator simply has to remember to run "make", and the Makefile re-builds, and atomically publishes, the new DNS database.

The simplest makefiles are of the scale exhibited at http://cr.yp.to/djbdns/run-server.html

But one can create significantly more ambitious makefiles than those. (-:

Re: Make for hipsters

#185

Post by jklowden »

0xmohit wrote: post #140

I prefer a help rule in the Makefile, like so: help: @grep -P '^[a-zA-Z_-]+:.*?## .*$$' $(MAKEFILE_LIST) | sort | awk 'BEGIN {FS = ":.*?## "}; {printf "\033[36m%-20s\033[0m %s\n", $$1, $$2}' Assuming that the trimmed Makefile read: build: ## Build the binary clean: ## Clean the binary and intermediate files distclean: clean ## Clean dependencies, intermediate files and binary deps: ## Install dependencies all: deps b…

Simplified: (no color, no grep)

    help:
        @awk -F ':.*##' '$$0 ~ FS \
                {printf "%15s%s\n", $$1 ":", $$2}' \
                        $(MAKEFILE_LIST) | sort

Re: Make for hipsters

#186

Post by madeofpalk »

chongli wrote: post #127
madeofpalk wrote: post #85

Earlier quoted context omitted.

I see this rhetoric being thrown around all the time, but I don't actually think its true in practice. Grunt came out in 2011 and Gulp came out 2 years later with a superior (IMHO) code-over-convention approach. They've kinda been doing their thing since then. Statements like seem to be nothing but FUD.

It's not about when things come out, it's when people start talking about them. I've been on an for 4 years (a relative newcomer, I know) and this is the first time I've seen either Grunt or Gulp mentioned.

So how can you be upset with the zeitgeist changing so frequently if it's taking to 4 years to hear about these widely used (in their field) tools?

Re: Make for hipsters

#187

Post by tomc1985 »

coldtea wrote: post #138
tomc1985 wrote: post #129

Earlier quoted context omitted.

"Hipster" carries a more detailed connotation than that, at least in the US. (Lots of fond memories arguing about the term in europe, where the word seems to lack its snobby, negative feel)

> "Hipster" carries a more detailed connotation than that, at least in the US. Yes, but this isn't the generic term "hipster", it's applied to a specific context, that is hipster programmers. > Lots of fond memories arguing about the term in europe, where the word seems to lack its snobby, negative feel I guess depends on where in Europe. In the place I'm aware of (e.g. not sure about Germany or nordic countries), it…

> Yes, but this isn't the generic term "hipster", it's applied to a specific context, that is hipster programmers.

Then he should say hipster programmers. I think of a less-parodied version of these guys: https://www.youtube.com/watch?v=IGkuxk-LPww

Also, the people I argued with were German. Perhaps a broad brush...

Re: Make for hipsters

#188

Post by jloughry »

0xmohit wrote: post #140

I prefer a help rule in the Makefile, like so: help: @grep -P '^[a-zA-Z_-]+:.*?## .*$$' $(MAKEFILE_LIST) | sort | awk 'BEGIN {FS = ":.*?## "}; {printf "\033[36m%-20s\033[0m %s\n", $$1, $$2}' Assuming that the trimmed Makefile read: build: ## Build the binary clean: ## Clean the binary and intermediate files distclean: clean ## Clean dependencies, intermediate files and binary deps: ## Install dependencies all: deps b…

If your grep is like mine you may need to add "-h" to the "-P" option to get the desired output.

Re: Make for hipsters

#189

Post by leni536 »

JdeBP wrote: post #181
efaref wrote: post #109

Earlier quoted context omitted.

The only case it becomes problematic is if you delete a header file, as make won't know how to remake it and won't recompile the C file (removing the dependency) until it has done so. There are two options to resolve this: Also specify -MP on the GCC command line, which causes GCC to emit an empty rule for all the header files, like this: foo.o: foo.c foo.h bar.h foo.h: bar.h: Alternatively, you can write a generic e…

Neither make nor any of its alternatives or improvements get header files completely right. This is because compilers simply do not emit all of the information. A build tool not only has to know about the header files found, to monitor them for changes, but also has to know about the places where header files were not found, to monitor for files suddenly appearing there. I wrote a C++ preprocessor that would spit out…

> A build tool not only has to know about the header files found, to monitor them for changes, but also has to know about the places where header files were not found, to monitor for files suddenly appearing there.

I wonder how my makefile fails here.

Re: Make for hipsters

#190

Post by majewsky »

gavinpc wrote: post #112
majewsky wrote: post #81

Earlier quoted context omitted.

> Tracking intra-file dependencies for proper recompilation is really difficult to for Scala code without reimplementing a huge chunk of a Scala compiler. tup ( http://gittup.org/tup ) has a really nice way of handling interdependencies. They set up some filesystem magic to figure out which files were read while compiling a certain target, and record these files as dependencies for the target. Another instance of a h…

I love tup so much. It's a "functional reactive" build tool that practically nobody's heard of, so I'd argue that it's even more "hipster" than make (whatever that means). When I decided I needed a single build system to replace a hodgepodge of stuff, I looked at make because that was apparently the go-to thing. It took me about 2 minutes to decide that I wanted no part of make. I'd assumed it was basically what Tup…

The only practical problem with tup is that it's not make, which creates friction for packagers. And since I'm doing some packaging work myself, I'm heavily optimizing for packager happiness.
Post reply on HN