>>> 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.
Time for Makefiles to Make a Comeback
51–60 of 116 posts
Re: Time for Makefiles to Make a Comeback
#52If 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,…
[deleted]
Re: Time for Makefiles to Make a Comeback
#53What do people think of 'tup'?
I really like it, but I don't know if it's worth the hassle. For example compared to ninja it isn't that much faster and it's missing a good configuration system anyway. Definitely better than Make though.
Re: Time for Makefiles to Make a Comeback
#54Earlier quoted context omitted.
Every folder gets its own little makefile. Calling those recursive shouldnt result in trouble?
You might like "Recursive Make Considered Harmful", Miller. http://aegis.sourceforge.net/auug97.pdf Although I suspect the main complaint (slow, due to checking directories where nothing has changed) has mostly been swept under the rug by increased CPU speeds some of the other items (managing dependencies, ordering, ...) are still worth considering today.
Tup solves this: http://gittup.org/tup/
Re: Time for Makefiles to Make a Comeback
#55Earlier quoted context omitted.
That's a rather dated view of what a build system should be. Most developers these days don't want to have to manually install all of a projects dependencies in order to build it. More importantly, there's also been a push towards wherever possible installing dependencies into sandboxes to try to prevent things like DLL hell, which isn't possible if you install dependencies at the OS level. I much rather just check o…
> 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'm curious how you would use Make to install dependencies. I'm aware of Guix, but that's probably an extreme example, most people probably aren't willing to sandbox literally their entire OS install, plus it's entirely unreasonable to require a particular OS in order to handle dependencies of your project. It shouldn't matter what OS I'm using (within reason), the project should have an automated way to install any dependencies it requires.
Here's the thing with Make, even if used only as part of a build system, it's both too complicated, and not complicated enough at the same time. The makefile format when used very sparingly isn't too bad, but once you pass needing more than 2 or 3 rules it gets unwieldy, and on any significantly sized project it will need more than 2 or 3 rules. Using autoconf and automake just proves the point, now you're using a build system to build your build system. Autoconf in particular is way too complicated, and an absolute nightmare to try to extend or customize.
Instead of using a tiny little sliver of make as essentially build system glue to connect the actual build tools together, why not just use slightly more powerful build tools and get rid of make all together?
Re: Time for Makefiles to Make a Comeback
#56I've been using make files constantly since '76 when I first started programming in (US) 5th grade. It has been one of my career amusements watching the build systems come and go. I gave up talking about Make years ago. There is a huge population of us that smile and get things done, while others screw around with new, complicated, never-learned-the-past tools. I use one of the earliest Make versions that barely does…
You make a few statements regarding films: First, "I've seen this version of Make used to build a feature animated film" and later you state "I write my Make films by hand".
I suspect the second statement might be a type-o -- accidentally using "films" in place of "files" -- but in the case that it's not, I wonder if you could detail the practice of "Make films" -- seems like it might be interesting.
Re: Time for Makefiles to Make a Comeback
#57I just got done watching a video called "make for reproducibility in science", which made a lot of sense. The impressio I get is people do weird things to make and then hit edge cases and complain.
> The impression I get is people do weird things to make and then hit edge cases and complain. Like not handling file paths that have spaces? [0] That's one hell of an edge case. [0] http://savannah.gnu.org/bugs/?712
I'm speechless at that link. I don't understand why something so basic isn't fixed yet in such an important package. I guess I can see why qmake/cmake have been eating the market share now.
For what it's worth, I am pretty sure one of my first BSD systems forced me into using snakecase so that would explain why I never hit that limitation. That said, make, being designed originally for C, and C being also known for snakecase, and early linux also known for discouraging spaces in names, I can see how this happened in the first place. What I don't understand is the lack of an implimented fix.
Re: Time for Makefiles to Make a Comeback
#58Nonononono. There's a reason makefiles have been reinvented 400 times: they're a nightmare. I don't love the alternatives, but they are pretty much all universally better.
Re: Time for Makefiles to Make a Comeback
#59Yeah, I'm writing a C build system just use shell+make, and it's work very nice for learning C programming and try some new ideas.
Re: Time for Makefiles to Make a Comeback
#60I used to be big fan of using Makefile for web development, but have since changed my mind, because make is not very good fit for watch-mode incremental building.
The data model of makefiles is perfect for watching and rebuilding. All you need to add is something that monitors the source files for any changes and runs 'make'.
For js code you often want hot module reloading which is probably very hard to get with make.