Live data from Hacker News

The Language Agnostic, All-Purpose, Incredible, Makefile

blog.mindlessness.life

71–80 of 124 posts

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

#71

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 .…

> If a commonly used tool changes its call in a new version, with README it’s a documentation issue, but with Makefile it’s broken software.

ie. the Makefile will be kept up-to-date

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

#72
Gnu make build systems can horrible to debug when they get complicated. Cmake or some of the other build systems can generate makefiles in addition of checks executed prior to building the project which are useful for finding all dependencies. I find it easier to work with cmake than with pure makefiles.

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

#73
post #72

Gnu make build systems can horrible to debug when they get complicated. Cmake or some of the other build systems can generate makefiles in addition of checks executed prior to building the project which are useful for finding all dependencies. I find it easier to work with cmake than with pure makefiles.

That's funny: I (and several other co-workers) hate cmake but make is OK. Not great but much, much better than cmake..

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

#75
What I love about Makefiles is that they just use the CLI tools. Full build tools like Gradle or Bazel require installing specific plugins and learning a new inferior syntax, making them a nightmare to use if you need to use a non implemented feature of the underlying tool. The biggest pain point is also that they don't even bother to print the actual command being executed!

I recently used make in a side project[1] to implement a "full" continuous delivery pipeline and it really was refreshing, despite the syntactic quirks.

[1]: https://github.com/Thiht/smocker/blob/master/Makefile

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

#76
post #7

Earlier quoted context omitted.

I agree, and the solution to this problem is to forbid filenames with spaces. The convenience of make and similar tools is much more important than spaces in filenames. File names with spaces should not be allowed in modern filesystems. When the user types a filename with spaces, the GUI should encode the space as a non-breaking space character, that does not cause havoc in scripts.

You're over 20 years too late to propose this.

We can move gradually towards this, not that there's anything lost besides a lot of time writing absurd quotes so that your script "supports spaces"

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

#77
post #34
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…

There are build systems that use strace to find dependencies. For instance tup [1][2] and Fabricate [3]. Also see this post by Waf which discusses some issues with this approach [4]

[1] http://gittup.org/tup/ [2] https://news.ycombinator.com/item?id=12622671 [3] https://github.com/brushtechnology/fabricate/wiki/HowItWorks [4] https://waf.io/blog/2015/02/using-strace-to-obtain-build.htm...

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

#78

Earlier quoted context omitted.

I can't tell if you are being sarcastic.

i am dead serious about that. Allowing the separator character in filenames is a nightmarish error.

The vast majority of users never even see the command line - why should they be dealing with the limitations imposed by it?

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

#79
post #21

I rely heavily on makefiles, but the gotchas lurking in make syntax are many and severe: http://www.conifersystems.com/whitepapers/gnu-make/

Note that the author of that paper (a friend of mine) wrote another build system, the dead-simple-but-awesome make.py. I have a mirror/fork of it[0], since it's been unmaintained for a while (but it mostly doesn't need any maintenance). The entire build system is a single Python script that's less than 500 lines of code. Rather than trying to fit complicated rules into Make's arcane syntax, rules are specified with a…

make.py looks great.

I also wrote a make replacement in python (2.7) [1]. I'm proud of it but it doesn't do parallel builds and there are so many other build tools that are better tested. But I'll put it here in case it gives anyone any ideas.

[1] https://github.com/robochat/buildbit

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

#80
post #78

Earlier quoted context omitted.

i am dead serious about that. Allowing the separator character in filenames is a nightmarish error.

The vast majority of users never even see the command line - why should they be dealing with the limitations imposed by it?

These users would never notice if their filenames are encoded using one type of space or the other inside the filesystem. That's a win-win!
Post reply on HN