5 ms·

> but I can share a makefile with confidence that any Linux/Mac OS/BSD can use it without needing any additional software I'm sure you're kidding, but in the c

by dijit 4y ago

> but I can share a makefile with confidence that any Linux/Mac OS/BSD can use it without needing any additional software I'm sure you're kidding, but in the case that you're not: Make portability is gross. We have ./configure steps precisely because Make is difficult w.r.t. portability, but even if that wasn't the case and you were just using make as a command executor: you still have enormous warts. Oh, and yeah, you'd need whatever additional software too. Be it: headers, linters, formatters, libraries or test suites that you've bundled. Valgrind is a popular make target, but "Make" does not bring in valgrind (for example). Honestly one of the most backwards things the Go community did was adopt "Make", it's so kludgey even as a pure command executor that I can't really take anyone seriously who argues for it's use. I'm not saying "Just" is a replacement, I don't know what is. Most of the arguments for using Make boil down to "I enjoy typing `make <something>`" and "you probably have it installed already?".

alisonatwork 4y ago
This. People here are acting like make is installed by default on all Linuxes, but it absolutely is not. And the various BSD makes are very different to GNU make. Make portability is bad enough on UNIX-like OSes, to say nothing of what a crapshoot it is on Windows. Even if you do have make installed on Windows, there's no guarantee that what it shells to is going to be able to run all the commands people tend to put in there. Plain old shell scripting is much more portable than make, because a shell is definitely installed on every UNIX-like OS, and there is a very clear baseline of functionality that works in every Bourne/POSIX descendant. And it's quite likely to exist on a modern Windows developer machine too because bash is bundled together with Git. My theory of writing developer scripts is to prefer the tool that already exists in the language you're developing. Gradle for JVM, npm for Node etc. Otherwise just use shell. Make feels like wrong tool for the job.
- velcrovan 4y ago
  This just in, Windows isn't UNIXy, film at 11 Let me know what shell scripting selectively builds only the artifacts whose dependencies have changed (honest question).
- crabmusket 4y ago
  > there is a very clear baseline of functionality that works in every Bourne/POSIX descendant Where is the best place to learn what this is? I'd love to make sure I'm writing portable shell scripts when I do have to. There's also the issue that "shell scripts" often involve using binaries which you might not even realise are binaries (is "echo" a shell builtin or a binary? I forget) and which may differ from system to system. I've been bitten by grep issues before writing scripts across Ubuntu and OSX.
  - JamesonNetworks 4y ago
    ChatGPT has done wonders for my understanding of bash. I presents me with lots of tedious things I would never spend time learning
  - deleted 4y ago
    [deleted]
  - nikvdp 4y ago
    https://www.shellcheck.net/ https://www.shellcheck.net/ and it’s accompanying cmdline tool/ lsp integrations is a lifesaver for preventing that kind of thing. It’ll warn you if you’re doing anything not portable and even smartly changes it’s behavior depending whether your shebang line uses bash or sh (iirc)
  - cpach 4y ago
    Do you need portable shell scripts though? IMHO, it really depends on the context. If I was about to ship an open source application that came bundled with some shell scripts, then I agree portability is good, so that I know the script would run for people who might not have Bash installed. But at ${DAYJOB} I much prefer to let Bash run all my scripts, and I make that explicit via ‘#!/usr/bin/env bash’. Bash is still evolving and the Bash devs are adding new features that I would miss in pure sh. Case in point: A (somewhat) reasonable way of working with arrays.
benatkin 4y ago
> I'm sure you're kidding, but in the case that you're not https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html
- dijit 4y ago
  Probably you're referring to: > Be kind. Don't be snarky. But, I'm not being snarky or rude... I'm just not 100% sure he is being sarcastic. Given that Make is not portable and does not include _any_ tools that it is commonly used to execute, I consider it hugely sarcastic. However, other lines were true and it sounds like it was written seriously, so, can't tell if sarcasm or not.
  - falcolas 4y ago
    Being fair, your rant is about autotools and c compilation, not make, so your own post is as equally suspect for being satire.
    - dijit 4y ago
      There is more to my rant than just autotools and C compilation though, and it applies equally. I went into more detail for you here: https://news.ycombinator.com/item?id=34319254 https://news.ycombinator.com/item?id=34319254 (btw, most of times I've used "Make" has been times where the pain has been done for me or I'm using Python, Go, Docker or in one case: Rust. I have never touched Autotools or C-compilation myself with Make, my arguments have nothing to do with C compilation at all.)
      - falcolas 4y ago
        If you’re complaining about ./compile or valgrind, you’re soundly in the world of autotools and C compilation. Not make.
        dijit 4y ago
        These are just examples of poor portability (thus workarounds) and tools that are not installed when you run `make` as the GP suggested, the claim was that you could write a make file and kinda not have to worry about anything else. Not the case. I could just as easily talk about the pathing issues between MacOS and Linux: or the multiplicity of issues surrounding `sed` (GNU) and `sed` (BSD), or that the `black` python formatter won't be installed by default. It is not as easy as the author claimed, you need whatever dependencies you call on, obviously.
falcolas 4y ago
Make works remarkably well. You’re just confusing it with C compilation. None of these complaints have anything to do with make. Autotools, which generate configure scripts, was built to work around the specific issues associated with old-school C cross platform compilation (with shared libraries, version differences, and misc libc editions). Ditto valgrind, et.al. So, yeah. Make’s fine. You just don’t like C. Which, that’s cool, just unrelated.
- dijit 4y ago
  I'm not writing C. so I'm not sure what you mean, I mentioned ./configure as a solution to a problem because it was obviously a big enough problem; To go into issues though: Make itself executes by default with `sh` which is wildly different between platforms. Even if you write portable enough shell; Paths are still incompatible between OS's and distros. You still must ship your tools, which is a direct contradition of what is mentioned. In fact; I just googled it and this chapter from Managing Projects with GNU Make; talks about the issues in making Make (GNU Make, as opposed to BSD Make, which is different enough to have broken my things!): portable https://www.oreilly.com/library/view/managing-projects-with/0596006101/ch07.html https://www.oreilly.com/library/view/managing-projects-with/...
  - falcolas 4y ago
    ./compile works around c cross compilation issues, where different platforms have different files with the same names. Fixing that within Make would require it to be platform aware. Not just “is this Linux” but “which flavor of Linux is this and what version of that flavor”. It’s also highly specific to C. Perhaps your other complaints here are valid, but they’re issues I’ve never run into myself, in my 20 odd years with it. EDIT: Would you blame Just for not handling C cross compilation capability built in? Would you blame Just if someone automates the creation of Just command files to work around a particularly nasty workflow?
    - dijit 4y ago
      I don't need to google to find fault, but I figured the make book might have something to say about portability and in better words than I can construct at 3am. Look, I'm not taking your tools away, there is no need to be defensive. Make isn't going anywhere, but it is a bad tool, the syntax is completely arcane and it's designed for things few people actually need these days. The most common case I've seen of modern Make usage is `make docker` and for Golang, where it doesn't get an opportunity to stretch its legs as a dependency manager at all -- making it a glorified task runner. The portability aspect is all I mentioned, because that was all that was in question. But if you really want me to get into it, I can be quite cruel. Just because you spent 20 years learning or using something does not mean it is a good tool, I'm glad it works for you, truly, but it is an abomination and people only continue to use it for a sense of sunk cost fallacy or by telling themselves that "most people have it installed already".
velcrovan 4y ago
I’m...talking about using make for its intended purpose, which is selectively building artifacts whose dependencies have changed, e.g. compile executable A if source code files X Y or Z have changed and leave it alone if not. What exactly are you talking about? Are you upset that make isn't a cross-platform package management system? You don't know what alternative there is to Make and then in the next breath you say the only arguments for it are personal preference?
- dijit 4y ago
  Oh excellent, then better (and more portable!) tools are available: http://pants.build http://pants.build https://ninja-build.org https://ninja-build.org https://buck.build https://buck.build and, if you hate yourself: https://bazel.build https://bazel.build > What exactly are you talking about? Are you upset that make isn't a cross-platform package management system? Ok, so you were serious with your claims of portability, that is concerning. The majority of times I've seen Make used it's primarily been as a task runner. For example: TAG=some-service SVC=website.com/$(TAG) BUILDER=golang:1.19-alpine export REVISION_ID?=unknown export BUILD_DATE?=unknown RUN=docker run --rm \ -v $(CURDIR):/opt/go/src/$(SVC) \ -w /opt/go/src/$(SVC) \ -e GO111MODULE=on build: ifeq ($(OS),Windows_NT) # Workaround on Windows for https://github.com/golang/dep/issues/1407 $(RUN) $(BUILDER) rm -rf vendor vendor.orig $(RUN) $(BUILDER) rm -rf vendor vendor.orig endif $(RUN) -e CGO_ENABLED=0 -e GOOS=linux $(BUILDER) \ go build -o service -ldflags "-s -X main.revisionID=$(REVISION_ID) -X main.buildDate=$(BUILD_DATE)" \ ./cmd/some-service/... # $(RUN) $(BUILDER) rhash --sha256 service -o service.sha256 docker build --tag="$(TAG):$(REVISION_ID)" --tag="$(TAG):latest" . run: docker-compose up serve: go run ./cmd/some-service/... dev: ulimit -n 1000 #increase the file watch limit, might required on MacOS reflex -s -r '\.go$$' make serve ^ the only thing this is "using" of Make is the name "Make" and it's so much worse to actually debug than a bash script, it's even got workarounds for various platforms inside of it.
linsomniac 4y ago
The question isn't if make is portable, the question is: is make any less portable than just?
sally_glance 4y ago
Are we going to dive into cmake now (sorry) Edit: We're actually using this - and I remember there was a modern version with colors and a cool short form. But I can't find it - anybody else got nice examples?

by dijit 4y ago

alisonatwork 4y ago

This. People here are acting like make is installed by default on all Linuxes, but it absolutely is not. And the various BSD makes are very different to GNU make. Make portability is bad enough on UNIX-like OSes, to say nothing of what a crapshoot it is on Windows. Even if you do have make installed on Windows, there's no guarantee that what it shells to is going to be able to run all the commands people tend to put in there. Plain old shell scripting is much more portable than make, because a shell is definitely installed on every UNIX-like OS, and there is a very clear baseline of functionality that works in every Bourne/POSIX descendant. And it's quite likely to exist on a modern Windows developer machine too because bash is bundled together with Git. My theory of writing developer scripts is to prefer the tool that already exists in the language you're developing. Gradle for JVM, npm for Node etc. Otherwise just use shell. Make feels like wrong tool for the job.

velcrovan 4y ago
This just in, Windows isn't UNIXy, film at 11 Let me know what shell scripting selectively builds only the artifacts whose dependencies have changed (honest question).
crabmusket 4y ago
> there is a very clear baseline of functionality that works in every Bourne/POSIX descendant Where is the best place to learn what this is? I'd love to make sure I'm writing portable shell scripts when I do have to. There's also the issue that "shell scripts" often involve using binaries which you might not even realise are binaries (is "echo" a shell builtin or a binary? I forget) and which may differ from system to system. I've been bitten by grep issues before writing scripts across Ubuntu and OSX.
- JamesonNetworks 4y ago
  ChatGPT has done wonders for my understanding of bash. I presents me with lots of tedious things I would never spend time learning
- deleted 4y ago
  [deleted]
- nikvdp 4y ago
  https://www.shellcheck.net/ https://www.shellcheck.net/ and it’s accompanying cmdline tool/ lsp integrations is a lifesaver for preventing that kind of thing. It’ll warn you if you’re doing anything not portable and even smartly changes it’s behavior depending whether your shebang line uses bash or sh (iirc)
- cpach 4y ago
  Do you need portable shell scripts though? IMHO, it really depends on the context. If I was about to ship an open source application that came bundled with some shell scripts, then I agree portability is good, so that I know the script would run for people who might not have Bash installed. But at ${DAYJOB} I much prefer to let Bash run all my scripts, and I make that explicit via ‘#!/usr/bin/env bash’. Bash is still evolving and the Bash devs are adding new features that I would miss in pure sh. Case in point: A (somewhat) reasonable way of working with arrays.

benatkin 4y ago

> I'm sure you're kidding, but in the case that you're not https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html

dijit 4y ago
Probably you're referring to: > Be kind. Don't be snarky. But, I'm not being snarky or rude... I'm just not 100% sure he is being sarcastic. Given that Make is not portable and does not include _any_ tools that it is commonly used to execute, I consider it hugely sarcastic. However, other lines were true and it sounds like it was written seriously, so, can't tell if sarcasm or not.
- falcolas 4y ago
  Being fair, your rant is about autotools and c compilation, not make, so your own post is as equally suspect for being satire.
  - dijit 4y ago
    There is more to my rant than just autotools and C compilation though, and it applies equally. I went into more detail for you here: https://news.ycombinator.com/item?id=34319254 https://news.ycombinator.com/item?id=34319254 (btw, most of times I've used "Make" has been times where the pain has been done for me or I'm using Python, Go, Docker or in one case: Rust. I have never touched Autotools or C-compilation myself with Make, my arguments have nothing to do with C compilation at all.)
    - falcolas 4y ago
      If you’re complaining about ./compile or valgrind, you’re soundly in the world of autotools and C compilation. Not make.
      - dijit 4y ago
        These are just examples of poor portability (thus workarounds) and tools that are not installed when you run `make` as the GP suggested, the claim was that you could write a make file and kinda not have to worry about anything else. Not the case. I could just as easily talk about the pathing issues between MacOS and Linux: or the multiplicity of issues surrounding `sed` (GNU) and `sed` (BSD), or that the `black` python formatter won't be installed by default. It is not as easy as the author claimed, you need whatever dependencies you call on, obviously.

falcolas 4y ago

Make works remarkably well. You’re just confusing it with C compilation. None of these complaints have anything to do with make. Autotools, which generate configure scripts, was built to work around the specific issues associated with old-school C cross platform compilation (with shared libraries, version differences, and misc libc editions). Ditto valgrind, et.al. So, yeah. Make’s fine. You just don’t like C. Which, that’s cool, just unrelated.

dijit 4y ago
I'm not writing C. so I'm not sure what you mean, I mentioned ./configure as a solution to a problem because it was obviously a big enough problem; To go into issues though: Make itself executes by default with `sh` which is wildly different between platforms. Even if you write portable enough shell; Paths are still incompatible between OS's and distros. You still must ship your tools, which is a direct contradition of what is mentioned. In fact; I just googled it and this chapter from Managing Projects with GNU Make; talks about the issues in making Make (GNU Make, as opposed to BSD Make, which is different enough to have broken my things!): portable https://www.oreilly.com/library/view/managing-projects-with/0596006101/ch07.html https://www.oreilly.com/library/view/managing-projects-with/...
- falcolas 4y ago
  ./compile works around c cross compilation issues, where different platforms have different files with the same names. Fixing that within Make would require it to be platform aware. Not just “is this Linux” but “which flavor of Linux is this and what version of that flavor”. It’s also highly specific to C. Perhaps your other complaints here are valid, but they’re issues I’ve never run into myself, in my 20 odd years with it. EDIT: Would you blame Just for not handling C cross compilation capability built in? Would you blame Just if someone automates the creation of Just command files to work around a particularly nasty workflow?
  - dijit 4y ago
    I don't need to google to find fault, but I figured the make book might have something to say about portability and in better words than I can construct at 3am. Look, I'm not taking your tools away, there is no need to be defensive. Make isn't going anywhere, but it is a bad tool, the syntax is completely arcane and it's designed for things few people actually need these days. The most common case I've seen of modern Make usage is `make docker` and for Golang, where it doesn't get an opportunity to stretch its legs as a dependency manager at all -- making it a glorified task runner. The portability aspect is all I mentioned, because that was all that was in question. But if you really want me to get into it, I can be quite cruel. Just because you spent 20 years learning or using something does not mean it is a good tool, I'm glad it works for you, truly, but it is an abomination and people only continue to use it for a sense of sunk cost fallacy or by telling themselves that "most people have it installed already".

velcrovan 4y ago

I’m...talking about using make for its intended purpose, which is selectively building artifacts whose dependencies have changed, e.g. compile executable A if source code files X Y or Z have changed and leave it alone if not. What exactly are you talking about? Are you upset that make isn't a cross-platform package management system? You don't know what alternative there is to Make and then in the next breath you say the only arguments for it are personal preference?

dijit 4y ago
Oh excellent, then better (and more portable!) tools are available: http://pants.build http://pants.build https://ninja-build.org https://ninja-build.org https://buck.build https://buck.build and, if you hate yourself: https://bazel.build https://bazel.build > What exactly are you talking about? Are you upset that make isn't a cross-platform package management system? Ok, so you were serious with your claims of portability, that is concerning. The majority of times I've seen Make used it's primarily been as a task runner. For example: TAG=some-service SVC=website.com/$(TAG) BUILDER=golang:1.19-alpine export REVISION_ID?=unknown export BUILD_DATE?=unknown RUN=docker run --rm \ -v $(CURDIR):/opt/go/src/$(SVC) \ -w /opt/go/src/$(SVC) \ -e GO111MODULE=on build: ifeq ($(OS),Windows_NT) # Workaround on Windows for https://github.com/golang/dep/issues/1407 $(RUN) $(BUILDER) rm -rf vendor vendor.orig $(RUN) $(BUILDER) rm -rf vendor vendor.orig endif $(RUN) -e CGO_ENABLED=0 -e GOOS=linux $(BUILDER) \ go build -o service -ldflags "-s -X main.revisionID=$(REVISION_ID) -X main.buildDate=$(BUILD_DATE)" \ ./cmd/some-service/... # $(RUN) $(BUILDER) rhash --sha256 service -o service.sha256 docker build --tag="$(TAG):$(REVISION_ID)" --tag="$(TAG):latest" . run: docker-compose up serve: go run ./cmd/some-service/... dev: ulimit -n 1000 #increase the file watch limit, might required on MacOS reflex -s -r '\.go$$' make serve ^ the only thing this is "using" of Make is the name "Make" and it's so much worse to actually debug than a bash script, it's even got workarounds for various platforms inside of it.

linsomniac 4y ago

The question isn't if make is portable, the question is: is make any less portable than just?

sally_glance 4y ago

Are we going to dive into cmake now (sorry) Edit: We're actually using this - and I remember there was a modern version with colors and a cool short form. But I can't find it - anybody else got nice examples?