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

Make for hipsters

mattandre.ws

Post reply on HN
Print view View original

151–160 of 200 posts

Re: Make for hipsters

#151

Post by moosingin3space »

mdaniel wrote: post #142
jsz0 wrote: post #132

I like to use makefiles for managing docker containers / images. For my needs it's a more practical and flexible solution than other docker orchestration / management tools I've tried. A few things I've learned that might be useful: * (cd /path/to/something && make goal) * You can use .DEFAULT_GOAL := goal_name to set the default target run by 'make' with no target name specified. * Adding .SILENT will suppress make…

> You can use .DEFAULT_GOAL := goal_name to set the default target run by 'make' with no target name specified. I had always, perhaps erroneously, thought that the very first goal in the file was the default one.

This is true -- the first goal declared is the default.

Re: Make for hipsters

#152

Post by profeta »

This tutorial is awful.

You should read the manual, which is shorter than that page!

make is NOT:

    alias:
        commands
this will bite you when you least expect. Make is:

    targetfile: inputfiles
        commands to get targetfile to exist
and you can use things like

    %.css_min: %.css
        sass stuff

    .PHONY: release
    # above is needed otherwise you won't build if there is a release/ dir
    release: release-min.css

    release-min.css: (list *.css_min files, there are helpers for it)
        cat *.css_min > release-min.css
anyway. you get the idea. work with files and why you need those files.

Re: Make for hipsters

#153

Post by ori_b »

WayneBro wrote: post #133
s_kilk wrote: post #58

Earlier quoted context omitted.

Unfortunately, many developers have a mortal fear of anything from before the year 2000. They've grown up with this tribal wisdom of unix and it's various tools being a beardy wilderness of byzantine hacks and toxic waste dumps. Meanwhile they'll merrily pile up a thousand node modules into a towering pillar of bad, just to run the equivalent of a shell one-liner, and call it a job well done.

Please show me the makefile for your Javascript project that will run perfectly on Linux, Windows and Mac with little to no setup. I doubt it exists. Until then, I'll stick with my Node.js build tools, thank you very much . Honestly, if anyone has an example of a makefile that can bundle my scripts, insert bundle links into my HTML which is compiled from jade and nunjucks templates, minify the JS, CSS and HTML and op…

I tend not to do much with Javascript, but if you have a project that I can take a shot at converting, I'd be curious to see what trouble you're running into.

Windows is the only real challenge there, but with mingw, I can't imagine that it's a serious one.

Re: Make for hipsters

#154

Post by Someone »

WayneBro wrote: post #133
s_kilk wrote: post #58

Earlier quoted context omitted.

Unfortunately, many developers have a mortal fear of anything from before the year 2000. They've grown up with this tribal wisdom of unix and it's various tools being a beardy wilderness of byzantine hacks and toxic waste dumps. Meanwhile they'll merrily pile up a thousand node modules into a towering pillar of bad, just to run the equivalent of a shell one-liner, and call it a job well done.

Please show me the makefile for your Javascript project that will run perfectly on Linux, Windows and Mac with little to no setup. I doubt it exists. Until then, I'll stick with my Node.js build tools, thank you very much . Honestly, if anyone has an example of a makefile that can bundle my scripts, insert bundle links into my HTML which is compiled from jade and nunjucks templates, minify the JS, CSS and HTML and op…

"Please show me the makefile for your Javascript project that will run perfectly on Linux, Windows and Mac with little to no setup."

One can argue that it would be better to solve that problem, rather than requiring everybody to sort-of solve it well enough to run one's own build.

Having said that, minimizing .js, .css, .html or .png files conceptually is the same as turning a .c into a .o, and bundling is conceptually the same as tarring or zipping a set of files, so I don't see why it wouldn't be possible to write a makefile that does that.

Re: Make for hipsters

#155

Post by koloron »

zeveb wrote: post #124

Make is old and crufty, but it's still the best at what it does. What I'd really love right now is a program which can look at a Go source tree and write make rules such that I don't have to run go build or go install unless dependencies have actually changed. It's really annoying to be pushing new images when nothing has actually changed.

> but it's still the best at what it does.

If "what it does" means "build complex software projects" I think your claim is rather debatable.

GHC is currently switching away from make after having already overhauled its make-based build system two times:

http://research.microsoft.com/en-us/um/people/simonpj/papers...

Re: Make for hipsters

#156

Post by coldtea »

nailer wrote: post #148
coldtea wrote: post #115

Earlier quoted context omitted.

> If you don't like putting small modules together to achieve a task, I have some news for you about shell and Unix... No, really. The "UNIX way" is not just "Use tons of small things to do a simple task, complexity of managing them be damned". It is indeed "do one thing and do it well", but that "thing" is usually high level enough and ready to go -- not something you need a whole stack of dependencies, configuratio…

Totally agreed, that's why most npm modules are focused on specific tasks, and we use github and npm to track how active projects are before installing them. It really seems like you don't do a lot of node - which is fine obviously, but you seem to have very strong opinions about it.

>It really seems like you don't do a lot of node - which is fine obviously, but you seem to have very strong opinions about it.

The first part of this is a guess -- and it's wrong.

I can't speak for "most npm modules" (there are 200.000 or so -- i've only used around 1000, transitive dependencies included) but even those focused on specific high level tasks tend to depend on tons of lower level modules of varying utility and quality -- living them open to things like the "leftpad" fiasco.

And using "github and npm to track how active projects are before installing them" is not really an answer to the UNIX way described.

First because with UNIX you don't even need to check. You know all the basic tools, from grep and unique, to watch and make, are there for the long term (and have been for 3, 4 decades).

Second, because with npm, even checking for popularity doesn't tell you much. Even the most popular modules can be dropped by their authors, rewritten in just 1-2 years to behave differently, fall out of favor and languish etc. Heck that's true even for npm itself (e.g. the changes for version 3, like the flat sub-packages), gulp (see the way the new gulp handles dependent tasks and the new syntax required) and everything else.

Heck, 6 years ago Backbone was merely just released. And from then on we already went from it being most used and "hot", to Angular, React, React+Redux and who knows what's next.

Re: Make for hipsters

#157

Post by snuxoll »

khedoros wrote: post #141
nailer wrote: post #100

Earlier quoted context omitted.

> Unfortunately, many developers have a mortal fear of anything from before the year 2000. They've grown up with this tribal wisdom of unix and it's various tools being a beardy wilderness of byzantine hacks and toxic waste dumps. Some stuff is genuinely awful. - Sendmail was ubiquitous, but it was, according to anyone who'd had either fleeting or deep experience with it, a beardy wilderness of byzantine hacks and to…

I like SysV-style init systems. I also don't mind RPM .spec files. They've always let me get the job done.

I hated SysV init, because writing init scripts is a chore - especially since you have little to no choice but to implement the detach/fork strategy to get a daemon to work properly without resorting to things like supervisord, etc. As much flak as systemd gets for trying to do too many tasks, I really find it a much better solution to `init`.

With that said, I agree about rpmspec's. They're simple to read and easy to maintain, it's part of the reason I chose CentOS and Fedora as our standard at work instead of Debian or Ubuntu.

Re: Make for hipsters

#158

Post by snuxoll »

gkya wrote: post #106
philh wrote: post #92

Earlier quoted context omitted.

I think Make is also broadly associated with autotools, which surely can't help its public image.

Autotools is smoking shit, but the make man page is a few pages and very comprehensive. Also the includable make libs that come with bmake allows many makefiles to be a few or one lines. Also, the best makefile I've ever seen is that of Linux, if someone considers to use make, must see that to convince himself, yes, it is possible to write a comprehensible, cross-platform and editable makefile for a big, deep project…

The concept of autotools is fine for the most part, it's just M4 that has a really bad rap (and rightfully so, it's a huge pain in the butt!). I have a couple toy vala and C++ projects I've written and autotools "just works" without much effort, but when I've needed to do something outside of the standard functionality the need to write M4 macros makes me quickly switch it out for CMake instead.

Re: Make for hipsters

#159

Post by snuxoll »

agentgt wrote: post #99
mhd wrote: post #34

Earlier quoted context omitted.

That was Java all over again. - you've got dependencies on some basic Unix commands (cp, rm etc.) in your tasks, so better rewrite that all to use your cross-platform language's facilities. - XML, erm, no, JSON, shall be your only file format.

Well in fairness Java does have the excuse that the cloud, and virtual images didn't exist and it was basically a Windows world. Linux/Unix was barely known to most developers. Java also pretty much brought the idea of dependency management (Maven) to mainstream programming languages (although I guess you could argue some of the early Linux did as well (RPM)). It is sort of interesting how Make is sort of like local…

> Java also pretty much brought the idea of dependency management (Maven) to mainstream programming languages

And Maven is still the only "package manager" I don't end up wanting to beat my head after using. For all the flak that pom.xml gets for being wordy, I know that after installing the JDK and maven all it takes is running `mvn package` and all my build plugins plus dependencies will be downloaded, installed, project compiled, tests run with whatever test runner I decided to use that year, and, assuming they passed, the project packaged up in a .jar or .war ready to be deployed.

Some more recent tools like cargo also get this right, but I don't have much of a use case for rust since the majority of my time is spend in web and desktop apps. But EVERYTHING being in one file and one tool makes getting down to business easy, there's no "make sure you run npm install before you call grunt/gulp/brocc/whatever" because maven handles it all.

Oh, as an added benefit, I don't scream about dealing with proprietary libraries like I do with .Net. The .Net SDK for our document management system has to be installed on all systems that use it via an MSI, yet the Java one is just a .jar with a couple dependencies, I whipped up a pom.xml for it in 30 seconds, pushed it to an internal maven repo and boom, done. Hell, at that point getting it packaged into an RPM (because I don't do "sprawl shit over the filesystem" deployments) took me another 3 minutes.

Re: Make for hipsters

#160

Post by mercurysmessage »

profeta wrote: post #152

This tutorial is awful. You should read the manual, which is shorter than that page! make is NOT: alias: commands this will bite you when you least expect. Make is: targetfile: inputfiles commands to get targetfile to exist and you can use things like %.css_min: %.css sass stuff .PHONY: release # above is needed otherwise you won't build if there is a release/ dir release: release-min.css release-min.css: (list *.css…

Yea, you can just do what he is doing using shell scripts anyway. I don't see why you'd use make for it.
Post reply on HN