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

The Language Agnostic, All-Purpose, Incredible, Makefile

blog.mindlessness.life

Post reply on HN
Print view View original

41–50 of 124 posts

Re: The Language Agnostic, All-Purpose, Incredible, Makefile

#41

Post by zwegner »

lhorie wrote: post #36
wwright wrote: post #30

Earlier quoted context omitted.

If you haven’t seen Bazel, you should take a look. It’s definitely not as minimalist, but it has a very, very similar model for specifying the build. In me experience, it’s pretty easy to get going, and it makes it pretty hard to screw up any of the important features of the build.

Unfortunately, Bazel also does not support file names w/ spaces https://github.com/bazelbuild/bazel/issues/374

Wow, that's kind of incredible. That bug has been open for years, and is only starting to see some progress. Lends some credence to my unsupported claim of Bazel being overengineered...

Re: The Language Agnostic, All-Purpose, Incredible, Makefile

#42

Post by a3n »

m463 wrote: post #40
lokedhs wrote: post #35

Earlier quoted context omitted.

That would be great, but significant whitespace doesn't seem to stop all the Python users out there.

I will say I like how python uses whitespace syntactically. The whitespace is consistent, makes programs readable and much more compact. make seems to be less consistent. I think it distinguishes between a space and a tab, which isn't clear without editor help.

Yeah, I wasn't specific here. Tabs and spaces in Make are different specific things. I also like Python's significant whitespace.

It's easy to mess up whitespace in Make and it might not complain about it. Mixed whitespace in Python will either work without problem, or it will tell you when it doesn't.

Make's whitespace is unnecessarily clever.

Re: The Language Agnostic, All-Purpose, Incredible, Makefile

#43

Post by datashaman »

goblin89 wrote: post #38

Unlike a target, .PHONY can be populated incrementally. For example, this: .PHONY: serve live-reload serve: init deps compile db-setup db-migrate rails server live-reload: yarn ./bin/webpack-dev-server --host 127.0.0.1 can become this, making things a tiny bit easier to maintain when there are many targets: .PHONY: serve serve: init deps compile db-setup db-migrate rails server .PHONY: live-reload live-reload: yarn .…

Some neat tricks to be found here for documenting makefiles. https://gist.github.com/prwhite/8168133

Re: The Language Agnostic, All-Purpose, Incredible, Makefile

#44

Post by pstuart »

Ambroisie wrote: post #22
aidenn0 wrote: post #18

Earlier quoted context omitted.

The poster is talking about a single command that generates multiple outputs. e.g. a codegen tool that generates "foo.c" and "foo.h"

Isn't the solution to that problem simply to use stamp files You declare foo-stamp as a dependency of both foo.c and foo.h. foo-stamp itself is dependent on the file used to generate those foo.* files. The recipe for foo-stamp invokes the code generator which updates the files, then you `touch foo-stamp`at the end of the recipe.

> Isn't the solution to that problem simply to use stamp files

TIL a new make trick. Thanks!

Re: The Language Agnostic, All-Purpose, Incredible, Makefile

#45

Post by john-radio »

adelarsq wrote: post #5
jstrong wrote: post #3

I like make, but I had a lot more luck with just/justfile, which is similar to make conceptually but with less idiosyncratic syntax/execution.

Just works with file names with spaces? https://stackoverflow.com/questions/9838384/can-gnu-make-han...

Apparently:

    $ cargo install just
    $ ...
    $ vi Justfile
    create:
      touch "Hello world";
    $ just create
    touch "Hello world";
    $ la
    'Hello world'   Justfile

Re: The Language Agnostic, All-Purpose, Incredible, Makefile

#46

Post by acqq »

ur-whale wrote: post #9

Make is great as a dependency resolution engine. For everything else, it is absolutely horrible. What I typically do is use make only for what it is good: as a dependency resolution back-end. All the build logic for my projects is written in Python, in an executable file stored in the project root directory and called "make" (I have "." in my PATH). The Python script, when it runs, generates on the fly a clean, lean,…

> Make as a solid back-end to solve the "what needs to be rebuilt" problem (especially the parallel version with -jXX)

I consider it a poor back-end for parallel execution, as it doesn't serialize the outputs.

I personally like ninja build tool as a very "low level" parallel "making" engine.

https://ninja-build.org/

"Command output is always buffered. This means commands running in parallel don’t interleave their output, and when a command fails we can print its failure output next to the full command line that produced the failure. "

Re: The Language Agnostic, All-Purpose, Incredible, Makefile

#47

Post by imglorp »

teddyh wrote: post #2

Make is great, and I wish more people would use it in place of whatever monstrosity is en vogue this week. However, there is one thing which Make absolutely cannot handle, and that is file names with spaces . If you have any risk of encountering these without any possibility of renaming them, you’ll sadly have to give up on using Make; it just won’t work.

And are we gonna talk about case-insensitive filesystems?

cringe

Re: The Language Agnostic, All-Purpose, Incredible, Makefile

#48

Post by draw_down »

teddyh wrote: post #2

Make is great, and I wish more people would use it in place of whatever monstrosity is en vogue this week. However, there is one thing which Make absolutely cannot handle, and that is file names with spaces . If you have any risk of encountering these without any possibility of renaming them, you’ll sadly have to give up on using Make; it just won’t work.

Stuff like this (and .phony) is why I can’t believe people take it seriously.

Re: The Language Agnostic, All-Purpose, Incredible, Makefile

#49

Post by henesy »

MisterTea wrote: post #8

There's also mk from bell labs which has been ported to *nix and is available in p9p (Plan 9 Port.) http://doc.cat-v.org/bell_labs/mk/

I generally prefer mk to make, I just find the way multiple mkfiles compose and some of the syntax changes pleasant.

A small change, but being able to just do $foo instead of $(foo) is so nice.

Re: The Language Agnostic, All-Purpose, Incredible, Makefile

#50

Post by joshuamorton »

zwegner wrote: post #34
wwright wrote: post #30

Earlier quoted context omitted.

If you haven’t seen Bazel, you should take a look. It’s definitely not as minimalist, but it has a very, very similar model for specifying the build. In me experience, it’s pretty easy to get going, and it makes it pretty hard to screw up any of the important features of the build.

Yeah, I know about Bazel, but only at a high level--I haven't used it. I generally think the hermetic build concept is a very good one, but IMO Bazel goes about it the wrong way, and is overengineered. Rather than needing custom-built infrastructure for every type of language supported, I'd prefer build systems to use lower level OS facilities for discovering dependencies and controlling nondeterministic behavior. Th…

> Rather than needing custom-built infrastructure for every type of language supported

My understanding is that bazel is moving away from this, so that you can define toolchains by saying "here is a binary that serves the job of linking/compiling stuff".

The challenge with your idea is that you're basically saying "hey, we should sandbox and introspect to intercept and modify their filesystem and network (at a minimum) accesses, across any number of versions and uses". Even just handling conditionally rewriting file writes/reads based on guessing whether something is an input or re-used output isn't that easy in general.

Post reply on HN