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

Time for Makefiles to Make a Comeback

medium.com

Post reply on HN
Print view View original

81–90 of 116 posts

Re: Time for Makefiles to Make a Comeback

#81

Post by hyperpape »

orclev wrote: post #55
mikegerwitz wrote: post #45

Earlier quoted context omitted.

> That's a rather dated view of what a build system should be The author mentions JavaScript, which has npm as the package manager, which isn't a build system. It can _invoke_ a build system, but the build output produced is separately published to npm, or the build is triggered by e.g. a post-install hook. I use GNU Make with npm. Some use e.g. Grunt. Etc. > More importantly, there's also been a push towards whereve…

For the most part, JavaScript doesn't need a build system, so from a practical standpoint npm is its build system. Most JS projects shouldn't require anything more complicated than npm install to put them in the proper location. Now you can argue for something like a minifier, and things like Typescript add a wrinkle (as it actually does need a build system), but all that should still be able to be handled by npm. I'…

JavaScript needs a build system: https://tomdale.net/2017/04/making-the-jump/

Re: Time for Makefiles to Make a Comeback

#82

Post by bryanlarsen »

abritinthebay wrote: post #75
hashmal wrote: post #65

TIL Make is not used widely anymore. I may live in a bubble, but my last use of it was… maybe 2 hours ago (to build someone else's project) and yesterday (to build one of my own projects).

It’s used for basically most C/C++ projects and somewhat outside of that. It’s not been adopted (with good reason) in many newer language communities, so depending on your tooling and platform you may see it less.

Yup, if Make was used extensively for Javascript, I wouldn't have had to file this feature request:

https://github.com/webpack/webpack-cli/issues/152

Re: Time for Makefiles to Make a Comeback

#83

Post by gkya »

dmytroi wrote: post #25

Make provides awesome UX: in most cases you just type "make" and stuff just works, but there is a tradeoff: it's nearly impossible to write a crossplatform make file. Why you ask? Try copying a file (or directory) from one location to another, sure "cp", but it's -R is different on Linux and macOS! And then comes Windows - there is no good built-in alternative to "cp" as it's hard to make "xcopy" to ignore failures i…

If you want to write a portable makefile, you use a CP variable which is conditionally set depending on what uname says, e.g. cp -r on GNU Linux and whatever it is on Mac OS. But also, copying files around is a bit out of make's scope, as it is a tool for transforming files. Most standard tools that are used in makefiles (sed, awk, m4, c toolchain) have posix interfaces, and other compilers usually don't have incompatible competing implementations. Even if you want to use a certain implementations features, say GNU features of awk, gawk+GNU coreutils are available for all popular systems, as well as bsdutils. Requiring them is better than when every program require its own build system because they are portable and reusable packages.

Re: Time for Makefiles to Make a Comeback

#85

Post by bb88 »

user5994461 wrote: post #51

>>> Time for Makefiles to Make a Comeback Until your build chain is f----- by the tab VS space issue of makefiles. Then abandon makefiles again, for good.

This is really just an editor issue. Editors can parse a make file and do the right thing these days.

Re: Time for Makefiles to Make a Comeback

#86

Post by Iv »

mikegerwitz wrote: post #40
Iv wrote: post #34

If you compare Makefiles to the JavaScript ecosystem it will do so favorably, but many things will. Make is a good build system but it is a shitty deployment system. Yes, you can do everything you want if you put enough effort in it as it is a complete scripting system, something many alternatives are not. It does not mean that it is a good idea to do so. Recently a client made me begrudgingly try Maven. 'Yet another…

Make isn't intended to be used for dependency management. With traditional `./configure && make && make install`, dependencies are detected by the configure script, or manually provided by the user if they have custom library paths. Dependencies are handled by your package manager or something else (be it submodules in git, custom scripts, etc). There's a separation of concerns. For generating those configure files,…

Well ./configure does not install dependencies either. Even worse: it fails at the first missing dependency instead of listing them. Making an automake project to compile is actually a long and manual process.

Just today I had to compile an older version of gimp, just a 2 years old one. Configure. Fails. Apt-get this. Configure. Fails. Apt-get that. Oh, no, configure doesn't want obscure-package4, it wants obscure-package2, that has been removed from your distribution's repos. Arrrrrr! Truth be told, I just rebooted on windows and dowloaded a binary from an archive.

With maven, I can just tell it which release I want and it just fetches it and all its dependencies, compiles them and installs them. Full auto. If I add a lib in my project, it adds it automatically and the intellisense works, the source navigation works.

Make is years behind.

Re: Time for Makefiles to Make a Comeback

#87

Post by Iv »

athenot wrote: post #43
mikegerwitz wrote: post #40

Earlier quoted context omitted.

Make isn't intended to be used for dependency management. With traditional `./configure && make && make install`, dependencies are detected by the configure script, or manually provided by the user if they have custom library paths. Dependencies are handled by your package manager or something else (be it submodules in git, custom scripts, etc). There's a separation of concerns. For generating those configure files,…

Yes Make does one thing and one thing well. Having said that, if you really want to manage dependencies with Make, it's still trivial to do a curl/yum/rpm install when some component is missing. I've done that in the form of a `make deps` pseudo-target, to prevent doing anything that the user doesn't expect.

> it's still trivial to do a curl/yum/rpm install when some component is missing.

Oh yeah? Which one? curl, yum, rpm, apt-get? All of them? Which revisions are you targeting? Which package names? And that only covers windows. A lot of apps need to be deployable under windows and OSX too.

If you start being even slightly cross-platform, you soon have your own build system.

Re: Time for Makefiles to Make a Comeback

#89

Post by mikegerwitz »

Iv wrote: post #86
mikegerwitz wrote: post #40

Earlier quoted context omitted.

Make isn't intended to be used for dependency management. With traditional `./configure && make && make install`, dependencies are detected by the configure script, or manually provided by the user if they have custom library paths. Dependencies are handled by your package manager or something else (be it submodules in git, custom scripts, etc). There's a separation of concerns. For generating those configure files,…

Well ./configure does not install dependencies either. Even worse: it fails at the first missing dependency instead of listing them. Making an automake project to compile is actually a long and manual process. Just today I had to compile an older version of gimp, just a 2 years old one. Configure. Fails. Apt-get this. Configure. Fails. Apt-get that. Oh, no, configure doesn't want obscure-package4, it wants obscure-pa…

> Even worse: it fails at the first missing dependency instead of listing them.

Yes, this is a fair criticism. Fortunately, many projects state their dependencies. But not all do. If I'm already on a Debian system that has another version of the package, `apt-get build-dep' is very helpful to get most of the way there. Of course this is completely outside Autoconf.

Whether it fails immediately or not depends on how the author writes `configure.ac'. Usually `AC_MSG_ERROR' is used right away, because it's convenient. Instead, some authors choose to set a flag and fail at the end.

Re: Time for Makefiles to Make a Comeback

#90

Post by dozzie »

Iv wrote: post #34

If you compare Makefiles to the JavaScript ecosystem it will do so favorably, but many things will. Make is a good build system but it is a shitty deployment system. Yes, you can do everything you want if you put enough effort in it as it is a complete scripting system, something many alternatives are not. It does not mean that it is a good idea to do so. Recently a client made me begrudgingly try Maven. 'Yet another…

> Make is a good build system but it is a shitty deployment system.

Because you really should not deploy things with your build system. It's the today's tooling that got this backward. For deployment you have much saner tools, like package systems.

Post reply on HN