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

191–200 of 200 posts

Re: Make for hipsters

#191

Post by voltagex_ »

snuxoll wrote: post #159
agentgt wrote: post #99

Earlier quoted context omitted.

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, p…

NuGet is the current way of doing packages for .NET and get the same experience as mvn package.

Re: Make for hipsters

#192

Post by lomnakkus »

majewsky wrote: post #81
lomnakkus wrote: post #50

Earlier quoted context omitted.

> Of course it is great when you write a language to also throw in a build tool, but in the end if the build tool re-implements 30% or so of make in a broken way I don't see the point. Well, other build tools sometimes also do a lot more than make ever did. (And in some areas, perhaps less.) Example: Cabal/cabal-install (for Haskell) can automatically fetch all your project's dependencies and automatically compile th…

> Tracking intra-file dependencies for proper recompilation is really difficult to for Scala code without reimplementing a huge chunk of a Scala compiler. tup ( http://gittup.org/tup ) has a really nice way of handling interdependencies. They set up some filesystem magic to figure out which files were read while compiling a certain target, and record these files as dependencies for the target. Another instance of a h…

Sure, tup is very nice, but it doesn't solve the problem in a way that leads to anywhere near efficient re-compilation on small changes (for Scala, at least -- it might be workable for Java). For that you need something like zinc[1]. This is because the dependency units in Scala don't map cleanly to files.

> Another instance of a hard problem ("reimplementing [...] a Scala compiler") that turns into a very easy problem once you look at it from the right angle.

Only if you don't solve the problem fully. TBH, not even zinc solves the problem 100% and sometimes does a little bit of unnecessary re-compilation. It is very good, though.

[1] https://github.com/typesafehub/zinc

Re: Make for hipsters

#193

Post by LukeShu »

wbl wrote: post #135
LukeShu wrote: post #126

Earlier quoted context omitted.

What do you mean by "dependencies in the form of variables"?

Let's say I need to build the library again with a different set of options. Make clean and rebuild is only solution, even if not needed.

How I handle that:

    .var.%: FORCE
    	@printf '%s' '$(subst ','\'',$($*))' | sed 's|^|#|' | $(WRITE_IFCHANGED) $@
    -include $(wildcard .var*)
    .PHONY: FORCE
Where WRITE_IFCHANGED is a program that essentially does 'cat > $1', but only if doing so would create or change the file. https://lukeshu.com/git/autothing/tree/build-aux/write-ifcha...

Then, if a file depends on the value of a variable, I have it depend on .var.VARNAME. Of course, that means you may have to do something like $(filter-out .var.%,$^) in the command to generate a file.

Re: Make for hipsters

#194

Post by snuxoll »

voltagex_ wrote: post #191
snuxoll wrote: post #159

Earlier quoted context omitted.

> 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, p…

NuGet is the current way of doing packages for .NET and get the same experience as mvn package.

Not even close. Just because Visual Studio will automatically download packages from NuGet when you click 'build' before it executes MSBuild doesn't mean your build server does, or when executing a build from the command line. They are two completely independent tools with almost no integration with each other, beyond maybe stuffing an MSBuild task in to handle nuget package restore before it loads any plugins.

With Maven everything is in ONE tool, and the ENTIRE configuration for the build is contained within your pom.xml. Custom maven repositories, what build plugins need to be installed, how the build plugins are configured, project dependencies, relationships between multi-module projects, what mojos run at what phases, it's all in a single easy to read, declarative XML file. MSBuild is a giant clusterfuck compared to Maven, and it's integration with NuGet is shoddy at best.

NuGet doesn't even allow me to specify repositories on a per-project basis to this day, everything has to be specified globally. There's a LOT more configuration required to get my build server set up to build .Net apps than anything compiled with Maven.

Re: Make for hipsters

#195

Post by voltagex_ »

snuxoll wrote: post #194
voltagex_ wrote: post #191

Earlier quoted context omitted.

NuGet is the current way of doing packages for .NET and get the same experience as mvn package.

Not even close. Just because Visual Studio will automatically download packages from NuGet when you click 'build' before it executes MSBuild doesn't mean your build server does, or when executing a build from the command line. They are two completely independent tools with almost no integration with each other, beyond maybe stuffing an MSBuild task in to handle nuget package restore before it loads any plugins. With…

You're right. I hope they get there eventually - NuGet has a lot of attention at the moment due to it being a critical component of .NET Core.

Solution level repositories might go some way to fixing your last issue, see https://github.com/voltagex/junkcode/blob/master/CSharp/zzCo...

Re: Make for hipsters

#196

Post by WayneBro »

nwmcsween wrote: post #174
WayneBro wrote: post #133

Earlier quoted context omitted.

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…

Sure github.com/nwmcsween/asm.css/Makefile

"that will run perfectly on Linux, Windows and Mac with little to no setup"? No.

I see no reason at all to use a Makefile in that project other than it being your personal preference. It's completely non-standard for web projects and it will only serve to confuse and annoy the next developer who wants to work on your code.

Node.js, NPM, Gulp and Grunt are all orders of magnitude easier to get running on a wide variety of operating systems than your typical C/C++ build tools. Furthermore, you don't have to learn some cryptic syntax to use them. It's all Javascript and JSON.

Re: Make for hipsters

#197

Post by nwmcsween »

WayneBro wrote: post #196
nwmcsween wrote: post #174

Earlier quoted context omitted.

Sure github.com/nwmcsween/asm.css/Makefile

"that will run perfectly on Linux, Windows and Mac with little to no setup"? No. I see no reason at all to use a Makefile in that project other than it being your personal preference. It's completely non-standard for web projects and it will only serve to confuse and annoy the next developer who wants to work on your code. Node.js, NPM, Gulp and Grunt are all orders of magnitude easier to get running on a wide variet…

Because gulp, grunt are not real build systems, they are glorified scripts that do whatever, there is no tracking of dependencies, nothing. Make isn't a cryptic syntax it's a quite simple language that took me about a day to understand fully.

Re: Make for hipsters

#198

Post by WayneBro »

nwmcsween wrote: post #197
WayneBro wrote: post #196

Earlier quoted context omitted.

"that will run perfectly on Linux, Windows and Mac with little to no setup"? No. I see no reason at all to use a Makefile in that project other than it being your personal preference. It's completely non-standard for web projects and it will only serve to confuse and annoy the next developer who wants to work on your code. Node.js, NPM, Gulp and Grunt are all orders of magnitude easier to get running on a wide variet…

Because gulp, grunt are not real build systems, they are glorified scripts that do whatever, there is no tracking of dependencies, nothing. Make isn't a cryptic syntax it's a quite simple language that took me about a day to understand fully.

Incorrect. Gulp and grunt can track dependencies the same way you do anything else with it...just add the right plugin.

Saying that gulp/grunt aren't real build systems because of one feature that you actually missed anyway is like saying that Javascript isn't a real programming language because it doesn't compile to assembly.

Practically nobody uses Make for JS outside of a few misguided folks. There are good reasons for that. One of them is that Make's craptic language is useless outside of that one single task. Another one is that Make sucks at cross-platform. It forces you to use OS tools that don't exist on every OS. Meanwhile, Node.js tools work everywhere.

Re: Make for hipsters

#199

Post by groovy2shoes »

jomar wrote: post #66
nneonneo wrote: post #24

The single biggest piece of advice I can give for Make is to make sure your text editor uses real tabs in Makefiles. My personal preference for everything is spaces (mostly a habit learned from Python's PEP 8), but Make doesn't honour spaces for indentation - only tabs. Despite being an obvious usability hole, this has never been fixed. Exacerbating the issue is the poor error message given upon encountering a space-…

That's an error message from GNU Make. I'm not sure what version of GNU Make you're using, because GNU Make has emitted the following since 1998: Makefile:2: *** missing separator (did you mean TAB instead of 8 spaces?). Stop. See 2c64fb221a265f9e7fc93374906b1e7540377561: 1998-09-04 Paul D. Smith * read.c (read_makefile): If we hit the "missing separator" error, check for the common case of 8 spaces instead of a TAB…

You can also add a line like this to your .vimrc:

  au FileType make setlocal ts=4 sts=4 sw=4 noet
and have vim automatically use "hard" tabs when it detects that you're editing a Makefile. Of course, you can s/4/2/g or whatever your preferred tab width is.

Re: Make for hipsters

#200

Post by groovy2shoes »

teddyh wrote: post #75

Meanwhile, there’s a perfectly good introduction in the GNU Make manual: https://www.gnu.org/software/make/manual/make.html#Introduct... Also available in print: https://shop.fsf.org/books-docs/gnu-make-version-381

I learned how to use make by reading OpenBSD's man page for it[1]. It's written extremely well, and is concise yet comprehensive. Of course, it's specific to BSD make, but most of the concepts are portable to GNU make with some caveats. FreeBSD and NetBSD, iirc, both have similarly high-quality manuals for their respective makes, and I've come to favor BSD make in general, using bmake[2] on Linux and Cygwin for my own projects (bmake being a portable, packaged-up version of NetBSD's make).

[1]: http://man.openbsd.org/OpenBSD-current/man1/make.1

[2]: http://www.crufty.net/help/sjg/bmake.htm

Post reply on HN