Live data from Hacker News

Make for hipsters

mattandre.ws

131–140 of 200 posts

Re: Make for hipsters

#131
post #58
post #10

Do so many people who go on this site not know how to make makefiles? Also why is it for hipsters? Or is the article for hipsters? Why does the author call his own published notes factually inaccurate? Why is it hacky to use a makefile? Is this all a big ruse?

Unfortunately, many developers have a mortal fear of anything from before the year 2000. They've grown up with this tribal wisdom of unix and it's various tools being a beardy wilderness of byzantine hacks and toxic waste dumps. Meanwhile they'll merrily pile up a thousand node modules into a towering pillar of bad, just to run the equivalent of a shell one-liner, and call it a job well done.

By the same token, old shit isn't good by dint of its age.

Re: Make for hipsters

#132
I like to use makefiles for managing docker containers / images. For my needs it's a more practical and flexible solution than other docker orchestration / management tools I've tried. A few things I've learned that might be useful:

* (cd /path/to/something && make goal)

* You can use .DEFAULT_GOAL := goal_name to set the default target run by 'make' with no target name specified.

* Adding .SILENT will suppress make entering/leaving directory messages. Probably wise to be careful with one until you're 100% sure you're not ending up in an unintended directory doing nasty things.

* You can use $(COLOR) = `tput setaf x' and $(RESET) = `tput sgr0` to add colors to your make output. For example @echo "$(RED)ERROR!$(RESET)"

* Use if ! -f conditionals to start goals that rely on external scripts/programs. Otherwise make will run until it hits the error which will leave you with a partially completed goal.

  goal:

    @if [ ! -f ./scripts/blah.sh ]; then echo "ERROR: ./scripts/blah.sh not found"; exit 1; fi

    @echo "without the if ! -f this command would run"

    @echo "and so would this one"

    @./scripts/blah.sh $(IMPORTANT_STUFFS)

    @echo "but not this one"

Re: Make for hipsters

#133
post #58
post #10

Do so many people who go on this site not know how to make makefiles? Also why is it for hipsters? Or is the article for hipsters? Why does the author call his own published notes factually inaccurate? Why is it hacky to use a makefile? Is this all a big ruse?

Unfortunately, many developers have a mortal fear of anything from before the year 2000. They've grown up with this tribal wisdom of unix and it's various tools being a beardy wilderness of byzantine hacks and toxic waste dumps. Meanwhile they'll merrily pile up a thousand node modules into a towering pillar of bad, just to run the equivalent of a shell one-liner, and call it a job well done.

Please show me the makefile for your Javascript project that will run perfectly on Linux, Windows and Mac with little to no setup.

I doubt it exists. Until then, I'll stick with my Node.js build tools, thank you very much.

Honestly, if anyone has an example of a makefile that can bundle my scripts, insert bundle links into my HTML which is compiled from jade and nunjucks templates, minify the JS, CSS and HTML and optimize my images...I'd love to see that.

Re: Make for hipsters

#134
post #57
post #22

Earlier quoted context omitted.

You already found at least one. Also try anyone with a degree in computer science. I'd wager it's in most first year courses; it was in 3 of mine. Also you could consult anyone who spends a lot of time working on/programming for Linux and/or in C/C++. And it's really easy, and there's tons of literature on it on the internet. And it has a manpage.

I never encountered make in any assignment during my studies. It certainly wasn't mentioned in the lectures. At my university, you didn't learn any tooling at all, if you thought you needed it you had to teach yourself.

My professor encouraged us to learn Make but ultimately provided the file for us in every project.

Re: Make for hipsters

#135

Earlier quoted context omitted.

Well, Make could figure them out, for example by using the Linux ptrace syscall, or by using libfuse. However, my biggest problem with Make is still that it does not allow for dependencies in the form of variables.

What do you mean by "dependencies in the form of variables"?

Let's say I need to build the library again with a different set of options. Make clean and rebuild is only solution, even if not needed.

Re: Make for hipsters

#136
post #135

Earlier quoted context omitted.

What do you mean by "dependencies in the form of variables"?

Let's say I need to build the library again with a different set of options. Make clean and rebuild is only solution, even if not needed.

You could also output to different directories, depending on the values of variables, like for separate debug and release builds.

Of course, this is a work-around for variable dependencies. You'd have to change the filename somehow for every variable that you want to track.

Re: Make for hipsters

#137
post #100

Earlier quoted context omitted.

> Unfortunately, many developers have a mortal fear of anything from before the year 2000. They've grown up with this tribal wisdom of unix and it's various tools being a beardy wilderness of byzantine hacks and toxic waste dumps. Some stuff is genuinely awful. - Sendmail was ubiquitous, but it was, according to anyone who'd had either fleeting or deep experience with it, a beardy wilderness of byzantine hacks and to…

Respectfully: > - SysVinit sucked too, regardless of which replacement you prefer. > - RPM's macro-based .spec file format? Awful. These are opinions, which is valid. If you want to have some fun. install centos7 in a vm. Run yum update systemd. Reboot. Your vm is now bricked. Rpm spec files can be annoying, but what is more annoying to me is the spec behavior changing between rhel/centos 5, 6 and 7.

> If you want to have some fun. install centos7 in a vm. Run yum update systemd. Reboot. Your vm is now bricked.

Yeiks.

Re: Make for hipsters

#138

Earlier quoted context omitted.

> Do so many people who go on this site not know how to make makefiles? You'd be surprised. Especially if they work outside C/C++, and do e.g. mostly web development, they neither care much, not know much about makefiles. At best the know to configure, make and make install something on their Linux, but most haven't even tried that. > Also why is it for hipsters? Or is the article for hipsters? The article is (suppos…

"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 is indeed negative. E.g. this is about hipsters from a UK perspective:

https://www.youtube.com/watch?v=lVmmYMwFj1I&feature=youtu.be

Re: Make for hipsters

#139
post #135

Earlier quoted context omitted.

What do you mean by "dependencies in the form of variables"?

Let's say I need to build the library again with a different set of options. Make clean and rebuild is only solution, even if not needed.

What I do is split the makefile in two.

There's a top level makefile with targets like "make debug" and "make release". Those invoke a secondary makefile that actually builds things and takes options on the command line. That way I can build different configurations to different directories without having to copy/paste all of the rules for each configuration of each file.

For example, the main makefile for Wren[1] has rules like:

    debug:
      @ $(MAKE) -f util/wren.mk MODE=debug
That util/wren.mk [2] then uses "MODE" and a few other options, like:

    # Mode configuration.
    ifeq ($(MODE),debug)
      WREN := wrend
      C_OPTIONS += -O0 -DDEBUG -g
      BUILD_DIR := $(BUILD_DIR)/debug
    else
      WREN += wren
      C_OPTIONS += -O3
      BUILD_DIR := $(BUILD_DIR)/release
    endif
It has the real rules for compiling files:

    # VM object files.
    $(BUILD_DIR)/vm/%.o: src/vm/%.c $(VM_HEADERS)
      @ printf "%10s %-30s %s\n" $(CC) $
Took me a while to come up with this and quite some time to get it working, but I've been pretty happy with it so far.

[1]: https://github.com/munificent/wren/blob/master/Makefile

[2]: https://github.com/munificent/wren/blob/master/util/wren.mk

Re: Make for hipsters

#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 build ## Get dependencies and build binary

   release: distclean all ## distclean + all

Now issuing make help would display:

   all                  Get dependencies and build binary
   build                Build the binary
   clean                Clean the binary and intermediate files
   deps                 Install dependencies
   distclean            Clean dependencies, intermediate files and binary
   release              distclean + all
Post reply on HN