I 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.
Time for Makefiles to Make a Comeback
21–30 of 116 posts
Re: Time for Makefiles to Make a Comeback
#22I'm confused So its agreeable that the building pipeline of NPM calling some packer does replace any-other-language calling any-other-packer, but what is the point in replacing the role of `npm build`, with a makefile that just calls what npm would of called anyways? replacing make with npm with make-calling-npm?
I wrote a bit about an approach I'm using, A Touch Of Make (ATOM), which helps provide better developer UX across teams - particularly ones working on microservices. https://www.alexhudson.com/2017/04/26/articulating-atom-appr... You're right, replacing "npm build" with "make build" doesn't win you anything. But that's only true on the small scale. In a service world, there are lots of projects, each with different r…
I tried this approach. It never works in the long run. The Python developers wanted Make for the few commands they needed in their projects. The JVM folks had Gradle. The Python folks refused to learn Gradle (because of some argument like: rah rah rah JVM tools hard; Make easy! Make all you need. If Make isn't enough your language is garbage).
So the JVM folks created a crappy Makefile that accomplished some of the basic stuff to appease the Pythonistas. Meanwhile the JVM folks continued to use Gradle directly and the Python folks who had to work on the JVM projects got a shittier experience through the Makefile. As new tasks were added to build process the JVM folks would just write custom Gradle tasks to accomplish the job which would drive the Python folks nuts because they wanted shell scripts or make targets invoking shell scripts or whatever.
My only take away from this experience was developer tooling sucks and there is no one size fits all approach to build systems. Try to stick to a convention within an ecosystem (e.g. all JVM projects should use one of Gradle/Maven/Sbt), but don't try and get cute with making stuff more common than it has to be.
Re: Time for Makefiles to Make a Comeback
#23Earlier quoted context omitted.
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'.
That sounds like a great idea. Does anything like that exist already?
There's "when-changed" in pip.
pip install when-changed
when-changed *.tex -c "make all && echo 'done'"
Re: Time for Makefiles to Make a Comeback
#24For a better "make" try "do" (also known as "DJB redo"). It's designed by Dan Bernstein of crypto fame and implemented by Avery Pennarun now at Google. http://apenwarr.ca/log/?m=201012#14 I will contribute $100 to any Rust leader who wants to start coding "do" in Rust.
This seems like a prime moment to ask for a review of https://github.com/sagebind/rote
Re: Time for Makefiles to Make a Comeback
#25Make 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 if target file/directory already exist (it tends to ask if you want to overwrite it or not), WSL might fix that in the future, but currently it's quite slow on IO side of things. So, sure given enough time and kung-fu we can write crossplatform make files ... but even if copying one silly file is such PITA .. it's hard to advocate for make in 2017. Probably the wisest solution is just using make to run something more comfortable, for C/C++ it can be cmake, premake, tup, etc. But then again: if I need to add something, like another build step, do I add it to the tool of choice or make? It's a very hard balance to sustain.
PS. Copying files specifically is such huge PITA that cmake implements crossplatform copy for you, just run "cmake -E copy $in $out" (can be added as add_custom_command in CMakeLists.txt)
Re: Time for Makefiles to Make a Comeback
#26For a better "make" try "do" (also known as "DJB redo"). It's designed by Dan Bernstein of crypto fame and implemented by Avery Pennarun now at Google. http://apenwarr.ca/log/?m=201012#14 I will contribute $100 to any Rust leader who wants to start coding "do" in Rust.
This seems like a prime moment to ask for a review of https://github.com/sagebind/rote
Rote is a great accomplishment. IMHO it's superior to Make, Rake, Cake, etc. Thank you for writing this!
If you're curious, take a look at Do. It's like all of the above, yet flipped over on their heads. The value of Do is in the design, which is essentially the opposite of Make. Do leverages the composability of items, files, scripts, artifacts, and typical Unix pipes.
I would be very interested in your opinions about Do, and if you want the $100 to jumpstart working on Do in Rust, let me know how to donate to you.
Re: Time for Makefiles to Make a Comeback
#27I'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 anything beyond recognize rules, rule actions, and simplistic macros. I've seen this version of Make used to build a feature animated film. Witnessing the versatility of that feature film's multitude of software and renders and composites all built through Make taught me Make is the only tool needed for any building of anything.
I remember when MS introduced a Make with extensions, and many developers ran over and fucked up their build environments, starting them on the path to the complex manual required build mess most people have today.
I write my Make films by hand, still. It is that easy. And you really should have a build environment that is that easy. When you need it easy, as in some major deadline and crap is broken, you will thank yourself.
Re: Time for Makefiles to Make a Comeback
#28Earlier quoted context omitted.
Friends don't let friends write Makefiles at all. The author does not appear to be familiar with them, except for the trivial examples in this post.
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.
Re: Time for Makefiles to Make a Comeback
#29Make 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…
maybe projects should have their own ./bin folder for make to use and have those command refer to the right native command.
mixing make with a modern scripting language would make this possible.
Re: Time for Makefiles to Make a Comeback
#30Friends don't let friends write recursive makefiles.
Friends don't let friends write Makefiles at all. The author does not appear to be familiar with them, except for the trivial examples in this post.
The types of trivial examples in the post are exactly what you should use makefiles for. make excels at managing simple file transformations: you get into trouble when you try to do complex cross-platform scripting with it.