Our great sponsors
-
The article has the following near the end:
"To see more real-world examples of makefiles, see my [World Atlas](https://github.com/mbostock/world-atlas) and [U.S. Atlas](https://github.com/topojson/us-atlas) projects, which contain makefiles for generating TopoJSON from Natural Earth, the National Atlas, the Census Bureau, and other sources."
I checked those repositories because the descriptions of the makefiles sound interesting, but I couldn't find the makefiles. Am I looking wrong?
-
I imagine many of Mike's points would be addressed just as well by Just or most any other task runner... but I thought his main point of "Makefile as documentation" was valuable.
After reading this way back in 2015 I decided to give it a try for a not-code-related task: downloading a book from the internet archive, copying out all the images, and running some adjustments and conversions on them with ImageMagick:
https://github.com/beardicus/bk-fig-phillips
It was fairly ridiculous but works well and I learned a lot.
-
SonarLint
Clean code begins in your IDE with SonarLint. Up your coding game and discover issues early. SonarLint is a free plugin that helps you find & fix bugs and security issues from the moment you start writing code. Install from your favorite IDE marketplace today.
-
The article has the following near the end:
"To see more real-world examples of makefiles, see my [World Atlas](https://github.com/mbostock/world-atlas) and [U.S. Atlas](https://github.com/topojson/us-atlas) projects, which contain makefiles for generating TopoJSON from Natural Earth, the National Atlas, the Census Bureau, and other sources."
I checked those repositories because the descriptions of the makefiles sound interesting, but I couldn't find the makefiles. Am I looking wrong?
-
I've been working on a tool called Knit (https://github.com/zyedidia/knit) that I think is similar to what you are looking for. Essentially, a Knitfile is a Lua program with Make's declarative rule syntax baked in. It is like Make (with some additional changes inspired by Plan9 mk), but where Make's custom scripting language is replaced with Lua. It's still in progress (I'm currently using it in some projects, and then will likely make some more changes based on my experiences), but I hope to release a stable version in the next few months. If you or others also have feedback, please let me know!
-
SheetJS js-xlsx
📗 SheetJS Spreadsheet Data Toolkit -- New home https://git.sheetjs.com/SheetJS/sheetjs
We've used Make for more than 10 years in our open source JS projects (e.g. https://github.com/SheetJS/sheetjs/blob/github/Makefile ). In 2012 it was a controversial decision given the proliferation of JS task runners and build tooling like Jake and Cake and Grunt and Gulp.
Many of the proposed alternatives "came and went". Others have seen massive breaking changes that force users to roll back to unsupported versions of NodeJS or other software (not too dissimilar to maintaining a Windows XP machine to run old versions of software). But the Makefiles from 2013 still work in 2023.
-
Why not just bash: https://github.com/gnat/doit
Honorable mention: single python script.
-
* order-only prerequisites - X must happen before Y if it's happening but a change in X doesn't trigger Y
This is just a small selection and there are missing things (like how to handle rules that affect multiple targets).
It's all horrible and complex because like a lot of languages there's a manual listing the features but not much in the way of motivations for how or why you'd use them so you have to find that out by painful experience.
It's also very difficult to address the warts and problems in (GNU) make because it's so critical to the build systems of so many packages that any breaking change could end up being a disaster for 1000s of packages used in your favorite linux distribution or even bits of Android and so on.
So it's in a very constrained situation BECAUSE of it's "popularity".
Make is also not a good way to logically describe your build/work - something like Meson would be better - where you can describe on the one hand what a "program" model was as a kind of class or interface and on the other an implementation of the many nasty operating system specific details of how to build an item of that class or type.
Make has so many complex possible ways of operating (sometimes not all needed) that it can be hard to think about.
The things that Make can do end up slowing it down as a parser such that for large builds the time to parse the makefile becomes significant.
Make uses a dependency tree - when builds get large one starts to want an Inverted Dependency Tree. i.e. instead of working out what the aim of the build is and therefore what subcomponents need to be checked for changes we start with what changed and that gives us a list of actions that have to be taken. This sidesteps parsing of a huge makefile with a lot of build information in it that is mostly not relevant at all to the things that have changed. TUP is the first tool I know about that used this approach and having been burned hard by make and ninja when it comes to parsing huge makefiles (ninja is better but still slow) I think TUP's answer is the best https://gittup.org/tup/
-
InfluxDB
Access the most powerful time series database as a service. Ingest, store, & analyze all types of time series data in a fully-managed, purpose-built database. Keep data forever with low-cost storage and superior data compression.
-
Hm yes now I remember that point about how the data is anonymous Python objects that you can pass around to functions.
Are there any open source examples? I looked around the github account, but I mostly remember this tool
https://github.com/stb-tester/apt2ostree
I'd be interested in seeing the Python config and Ninja output, to see how it works. Right now it looks to me like the dependencies are more implicit than explicit, e.g. with your copen example
---
The system I ended up with is more like Bazel, but it's not building containers, so it's a slightly different problem. But I'm interested in building containers incrementally without 'docker build'.
I like the apt lockfile idea definitely ... However I also have a bunch of other blobs and tarballs, that I might not want to check into git. I guess you just put those in OSTree?
Our config looks like this
https://github.com/oilshell/oil/blob/master/core/NINJA_subgr...
And all the code is in build/ninja* of the same repo
-
oil
Oil is a new Unix shell. It's our upgrade path from bash to a better language and runtime. It's also for Python and JavaScript users who avoid shell!
Hm yes now I remember that point about how the data is anonymous Python objects that you can pass around to functions.
Are there any open source examples? I looked around the github account, but I mostly remember this tool
https://github.com/stb-tester/apt2ostree
I'd be interested in seeing the Python config and Ninja output, to see how it works. Right now it looks to me like the dependencies are more implicit than explicit, e.g. with your copen example
---
The system I ended up with is more like Bazel, but it's not building containers, so it's a slightly different problem. But I'm interested in building containers incrementally without 'docker build'.
I like the apt lockfile idea definitely ... However I also have a bunch of other blobs and tarballs, that I might not want to check into git. I guess you just put those in OSTree?
Our config looks like this
https://github.com/oilshell/oil/blob/master/core/NINJA_subgr...
And all the code is in build/ninja* of the same repo
