For those unfamiliar, FLTK is a cross-platform widget library in C++, with bindings to many other languages available. It's vaguely similar to something like Qt, but far simpler and far more developer-friendly. It is excellent; strongly recommended to all, for everything.
To do the stuff the blog post talks about you 'dpkg-buildpackage'. That's it.
After years of maintaining packages, I think I decided that much of the complexity is unfortunately warranted. You want stuff to work in all sorts of situations, with all sorts of different other things installed at the same time. You want upgrades to work. You want tests to work and to run, but probably you want to skip them when cross-building. You want the package to be co-installable across architectures. You want the package to be cross-buildable and to be usable to cross-build other packages. And you want your builds to be reproducible. And lots and lots of other things, all the while having to deal with upstreams that often don't care about many of these things.
I haven't seen any other packaging system that is both nicer and maintains Debian's high standards. Maybe something exists. I think Debian's biggest problem in this area is the documentation. The official docs should be more accessible, but that's a big job that nobody has stepped up to do. Yet.
Well, to be fair, no package maintainers are touching any of the stuff described here. All the "ar" and "control.tar" stuff is handled for you by the tools. This isn't a "this is how you build packages" article, it's a "here's how the guts of these packages work" article.
> I’d argue it’s a waste to use separate files here
Fine. Write a `make.sh` that parses the arguments; that would be better.
> How so?
Well, read the comments here. Do you sense that Make is a beloved tool? Most of the complaints are about some details about syntax, and those complaints are completely valid. If you use Make for its intended purpose, then it's still easily well-worth using, despite that. But if you use it as a glorified script, then all you see is the warts, without any upsides. And you then tell all your friends that "Make sux!" Which is a huge shame because Make is awesome.
The author is confused about what Make is for, and frankly this kind of thing is why Make gets a bad rap. Make is for traversing a graph to determine what should be built, and how to parallelize the steps. Here he doesn't have a graph or any dependencies defined at all. He does have a weird scripting language though, which more or less nobody likes.
If you want to mention this, then you very clearly haven't actually tried it. The implementation in GDB is more convenient than rr (you can start/stop recording at will), but it is also orders of magnitude less efficient. It's only usable for very small code snippets. Otherwise it takes effectively forever and/or runs out of resources.
This is the usual killer feature of something like rr. You debug, look at some variable: `p whatever`. You see that its value is wrong. You want to know where this wrong value came from, so you `watch -l whatever` and `rc`. Bam!
It graphically displays the relative sizes of things, and allows you to interactively zoom into any particular subdirectory to see the relative sizes of the things inside it
ROS is shit. In every possible way. It's a set of semi-related components, most of which can be done far better by doing it the normal way or writing it yourself. Nobody wants a "DDS" to simply send bits across and nobody wants their build system and nobody wants their half-assed protobuf reimplementation. And so on.
An important note about numpy broadcasting: numpy broadcasts from the back, so your life improves dramatically when you reference indices from the back as well: use axis references < 0. So if you want to reference a row: refer to axis=-1. This will ALWAYS refer to the row (first broadcasting dimension), whether you have a 1D vector or 2D matrix or any N-D array. Numpy is deeply unfriendly if you don't do this. To smooth out this an similar issues, there's the numpysane library. But simply using negative axis references goes a long way.
Avoiding rich models is a great thing to do if you don't model uncertainty: a beginner that didn't get enough useful calibration data will see poor uncertainties in the results. So I now use the splined models in pretty much all applications, and there are very few downsides. In my experience, every lens fits noticeably better with the richer model (the mrcal validation shows you this explicitly). I think you should look at the tour of mrcal; it's friendly.
That paper describes a rich splined model, very similar to the one used in mrcal. mrcal models projection (instead of unprojection like the paper does), which is better in a practical sense. Both work well to fit every lens. https://mrcal.secretsauce.net/splined-models.html
Uncertainty propagation. Richer models that fit better. Lots of feedback and metrics and visualization to evaluate the quality of the solve. Flexibility of the tool. Documentation.
Calibrating cameras is still important; it's only "mostly irrelevant in 2024" if you don't care about accuracy. Incidentally, tools like opencv and their ilk are also what you use if you don't care about accuracy. Modern tools like mrcal (https://mrcal.secretsauce.net/tour.html) are essential if you're trying to do long-range stereo or use wide lenses or have calibration instability or any number of other ever-present issues.
Yes. Recursing your Makefiles produces poor results. You know who hasn't read the Make manual and makes recursive Makefiles? The cmake devs.
If you truly need a lot of complexity, you can end up with unreadable Makefiles, as you say. Most projects don't need a lot of build logic, though. I have lots of projects using mrbuild, and their builds are clear and easily maintainable. If you truly need a lot more, then Make might not be the best choice. And you can do much better than cmake
There are plenty of options other than cmake. Ideally:
1. read the GNU Make manual
2. Write a tiny build system with Make or use any of the precanned ones. I use this: https://github.com/dkogan/mrbuild/ but there are many others
In any case, learning how to actually use Make is a prerequisite to having an opinion here.
Do we really need to wrap more crap around cmake? It's already wrapping make in an unknowable way, and this layer doesn't help. The challenges when using these things aren't in writing the thing, it's fixing it when it doesn't work, understanding the error messages, etc, etc. Each layer of crap is a huge step backwards. What would you say to the cowboy that will wrap cmkr in another layer of indirection?
And on top of that, Debian's bug tracker is where development happens (as opposed to Ubuntu's, which is a black hole). And packages that cannot be built, get a bug report BEFORE the release on Debian, but are silently not included in the release on Ubuntu. Ubuntu is "Debian with extra crap and extra bugs". Debian strongly recommended.
I think Make is exactly what you want, and I do recommend it to everybody, since the default alternative is usually something heinous like CMake which isn't really an improvement. You want the bit of logic to create a "build system" out of Make abstracted into a library, and then it's perfect. I use this: https://github.com/dkogan/mrbuild/ but there're many other ways to do it