The Language Agnostic, All-Purpose, Incredible, Makefile • Hacker News Board

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

#121

Post by emiliobumachar » Wed, Nov 20, 2019, 10:51 AM UTC

jobigoud wrote: post #27

enriquto wrote: 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.

> the GUI should encode the space as a non-breaking space character At this rate, why can't the tool itself escape the spaces from the filenames into non-breaking-spaces before processing?

Ambiguity. Two file names with the single difference that one has a breaking space and another a non- breaking space.

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

#122

Post by wirrbel » Wed, Nov 20, 2019, 10:06 PM UTC

renox wrote: post #73

wojciii wrote: 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..

IMHO make is not a great target for code generation. I.e. cmake should probably compile to something like ninja (the way meson does, actually I haven't checked if cmake could potentially compile to ninja).

Cmake is a weird tool, it's kind of ok, one can see why it was built, but it is astonishing how little benefit it provides over autoconf+automake as a makefile generator.

The thing about pure Makefiles is: they don't scale well. They usually start simple, and with project-growth the accumulate parameters, features and tasks, until they become an unbearable maintenance burden. I remember working on a project where I deleted a Makefile, and rewrote it from scratch, just because it contained the tinkering of about 10 devs, most of which were not actively developing the project anymore. In the end it was a magnitude smaller and faster. But: I am pretty sure it has either grown massively again over time, or it has fallen out of use.

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

#123

Post by wwright » Thu, Nov 21, 2019, 2:05 AM UTC

zwegner wrote: post #41

lhorie wrote: post #36

Earlier quoted context omitted.

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

Unicode handling can be really, really, really, hard, and I’m willing to bet a there’s a lot of edge cases there that are not unique to Bazel.

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

#124

Post by brandmeyer » Sat, Nov 23, 2019, 12:03 AM UTC

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

All targets can be populated incrementally. That's part of how GCC's family of -MD family works.