4 ms·
Makefiles aren't scary. But they're also not particularly good. I use Rake (or Gulp, or whatever) because then I can use Ruby (or JavaScript, or whatever). She
by eropple 9y ago
Makefiles aren't scary. But they're also not particularly good.
I use Rake (or Gulp, or whatever) because then I can use Ruby (or JavaScript, or whatever). Shell plumbing is fine for informal and small-scale stuff, and I make my code conform if somebody down the line (who may be me) wants to get out their duct tape, but the world is more complex than what /bin/sh can see. Shell is the lowest common denominator. Expecting everything to at all times be written in and for that lowest common denominator is not reasonable. We're a tool-using species and we refine tools over time to make them better. The profusion of tools happens because they iterate on each other to be better. If old tools were sufficient, people would use them because learning new ones is hard.
So, yes, you do need to learn those tools. Or invent a shell that isn't tooth-pullingly difficult to use with a JSON file (and do not say `jq`, I love `jq` as an inspector but it does not step to `JSON.parse` and a working subscript operator). Or change `make` so that a git checkout won't trigger a full rebuild. Lots of baseline, stump-simple things that `make` is just not going to do for you because it's built for a frankly outmoded method of development.
- GalacticDomin8r 9y ago> but the world is more complex than what /bin/sh can see That is blatantly false, but I get the premise behind it. Writing and maintaining complex stuff in bourne or bash is not fun or easy. I always use bourne until certain level of complexity or awkwardness is reached. It's pretty easy to write and dead simple to troubleshoot.
- eropple 9y agoBlatantly false? OK, put up. Forget `sh`'s JSON parsing, I'll make it easy on you--show me its arrays. Arrays, plural, you can't use $@ as a bail-out; I need more than one. Show me hashes. Show me sets. Show me the basic building-block primitives of software, because build pipelines are software. It's 2018. If your language can't do this stuff without babysitting, it effectively can't do it because nobody's got the time to babysit your easy-25%-of-Perl language And yeah, I did say `sh`, because that is what you can practically be expected to have kicking around alongside `make` on a system where I can't just install something worthwhile. If I have them, then there's no reason to write much harder to troubleshoot shell scripts (and, thank you quotebarf, more likely to be incorrect) than to open Pry.
- vlowther 9y agoBash, but... > --show me its arrays declare -a > Show me hashes. declare -A > Show me sets. See above > Show me the basic building-block primitives of software, thing() { local localVar # Yes, it would be nice to have lexical scope as well as # dynamic scope, but... }
- eropple 9y agoSure. All of which are clunky, opaque, and harder to work with than any other language I have used in the last decade. And besides: if I can install bash, I can install something specifically better for whatever I'm doing instead.
- mcguire 9y agoSpeaking as an (ex- (sort of)) sysadmin, "All of which are clunky, opaque, and harder to work with than any other language I have used in the last decade." Wrong question. A better one: Is it more clunky, opaque, and harder to work with than every other language that's appeared in the last decade? Because no one seems to agree on what is specifically better.
- eropple 9y agoI disagree that it is the wrong question. "Every other language" doesn't matter because I don't value homogeneity and I think that homogeneity of programming language is a fool's errand. I am comfortable shipping production code in most of the languages in current use; in my estimation, none of the major build systems out there are as opaque or difficult to use correctly as make/shell. (And I am what a current sysadmin would be if we did not call ourselves "devops engineers" now.)
- zippitydoodah68 9y agoAnd you are definitely not a sysad or any sort of sysadmin. The core mission of a sysad is to build the best environment possible while restricting that environment. You seem to be the sort of developer that developers love and the sort of sysadmin that gets fired in the first week Just my .02 after two and a half decades. Not to say that you are entirely wrong or your approach doesn't have merit in the new world (especially SV). But it doesn't work for sysadmins and production environments anywhere but your bubble. Not yet.
- adamc 9y agoYour second paragraph got to the heart of it. If we want to use some standard build toolchain, it needs to use a nice language and not feel obscure. I was explaining to someone a bash script I wrote, and he said "why not use Python". There were reasons but... he was right, Python would be much easier to use and maintain, and we have a lot more developers who know it. That said, Maven is incredibly suck-tastic.
- eropple 9y agoEh. It's not my favorite thing out there, but Maven's fine for what it is. It's designed for and explicitly for well-behaved Java artifacts. If your Java artifacts are not well-behaved, you're going to have a bad time--in my experience, most of those cases are doing things you probably shouldn't be doing. (You may be a wizard and have a reason to do them, for sure--but that's what writing Maven plugins is for. Or not using Maven. You've got choices.)
- clhodapp 9y agoGiven the limitations of the platform, there really isn't a such a thing as a well-behaved JVM library that depends on other libraries, unfortunately. Oracle really dropped the ball by only serving their own needs with the module system.
- eropple 9y agoCan you expand on this? Having done a pretty decent bit of JVM development, I've never really run into issues even doing some not-out-of-the-box stuff.
- weaksauce 9y agoWhat reasons? I did some ruby shell automation and it’s dead simple to get it working and working correctly. I imagine python has a similar story.
- gaius 9y agoBut they're also not particularly good. Million+ line codebases got errm made with make. In my experience people most sneering at it have far lesser demands on their tool...
- eropple 9y agoMillion+ line codebases were written entirely in COBOL. The world advances.
- gmfawcett 9y agoSome were, I guess, but hardly all of them. The Linux kernel is built with Make, for example.
- digi_owl 9y agoThere are been several attempts at introducing a new build system, but they have been all shot down over introducing dependencies.
- gaius 9y agoIf it ain't broke don't fix it! How many features could people have implemented or bugs fixed or general progress made instead of obsessing over tooling?
- pc86 9y agoIt's weird that you use the word "advances" to refer to JavaScript-based build processes.
- deleted 9y ago[deleted]
- mst 9y ago> `JSON.parse` and a working subscript operator https://github.com/ingydotnet/json-bash https://github.com/ingydotnet/json-bash source json.bash json='{"name":"Jason","friends":["Jimmy","Joe"]}' JSON.load "$json" joe=$(JSON.get /friends/1) JSON.put /friends/2 Jeff new_json=$(JSON.dump) It's still not as trivial as javascript, but "tooth-pullingly difficult" is a little unfair.
- eropple 9y agoAgain: sh, not bash. If I have the freedom to specify bash, I can specify something better than bash or sh.
- colanderman 9y ago> I use Rake (or Gulp, or whatever) because then I can use Ruby (or JavaScript, or whatever). You can use Ruby in Make. I don't know Ruby but here's some Python: SHELL = python .SHELLFLAGS = -c .ONESHELL: .DELETE_ON_ERROR: foo.txt: bar.json import json with open('$<') as input, open('$@', 'w') as output: output.write(json.load(input)['the_text']) (Caveat: I've never actually tried this at scale.) You can even use different languages for different recipes with per-recipe variable settings.
- eropple 9y agoHa, that's a neat trick! Trouble is, for either Python or Ruby it becomes tricky due to stuff like dependency management. You'll have to `bundle exec make` to get sane library paths for Ruby or `pipenv run` for Python, etcetera etcetera. At that point I think you might as well just use a language-native one. Great pull, though.
- avar 9y agoThe GP does this via a neat hack, but you can also do this in a much more understandable fashion by simply having the body of every Makefile rule start out by shelling out to some script in your favorite language. I think you're (understandably) misinformed about what Makefiles do because you've run into some bad ones. The thing they're doing is managing a N-level deep dependency tree in a declarative way. So if A->B->C you can run something to generate C, then B can run, and finally A, and this can all be done in parallel for hundreds of files. On the individual rule level this is really simple, e.g. just turning a .c file into a .o file, then finally some rule that depends on all *.o being generated creates a program out of them. The language-native ones are usually much worse. They're easier to use at the outset because they don't make you create this dependency graph, but that also means that they can't run in parallel on your N cores, and they usually suck at incrementally updating the build.
- colanderman 9y ago> The GP does this via a neat hack, but you can also do this in a much more understandable fashion by simply having the body of every Makefile rule start out by shelling out to some script in your favorite language. I'm not sure what you mean? How would this allow you to use, say, Python as the language for recipes? Just having Make drop straight into Python kind of defeats the purpose of Make.
- Sir_Cmpwn 9y ago>I use Rake (or Gulp, or whatever) because then I can use Ruby (or JavaScript, or whatever). This is an anti-feature. When you need this, your build is too complicated.
- Karrot_Kream 9y ago> Shell is the lowest common denominator. Expecting everything to at all times be written in and for that lowest common denominator is not reasonable Is it that hard to learn shell? Why is it so painful? What makes it the "lowest common denominator"? I use it all the time, but I admit at work I am one of the few. > Expecting everything to at all times be written in and for that lowest common denominator is not reasonable. We're a tool-using species and we refine tools over time to make them better. This is too vague. What makes a Ruby based build or JS based build a more "refined" tool? It sounds like familiarity is the real issue here. > If old tools were sufficient, people would use them because learning new ones is hard. How many people even know Makefiles these days anyway? The "modern" approach seems to be, learn a programming language and then try to do everything inside of it. Some languages are more interested in this cloistered philosophy than others (like JS). If anything, I think the reason these build tools keep being proliferated is because nobody wants to learn anything more than the bare minimum to "be productive" (which, depending on what you're working on, can be anything from pushing out customer demos for a company that will never sell, to microservices operating at scale). Learning a language and never leaving its paradigms/comforts is easy.