The InfoQ post mentions xcodebuild, but there is also a Makefile. I really appreciate the presence of a no-nonsense Makefile. No autoconf, no pkgconfig, just plain and simple make. Also, because nobody mentioned it: yes, it compiles on Linux out of the box.
Indeed, the current version of their Makefile is a great example of how to write a simple yet portable Makefile:
https://github.com/lzfse/lzfse/blob/33629bc65f4b356072c9a7d5...
> No autoconf, no pkgconfig, just plain and simple make.
While I agree with your sentiment, I believe that your statement about pkg-config goes a bit over the top.
Yes, the LZFSE project doesn't use pkg-config, but it also doesn't have any library dependencies. There's not a single "-l" argument in the linker flags.
If it had, I would prefer pkg-config over any other mechanism, as that is right now the best "simple yet portable" method of defining library dependencies.
Pkg-config is especially handy when it comes to cross-compiling, or when you have a special need for a static build instead of shared libraries.
Yet it forgets the MOST important thing: make uninstall.
Nothing worse than software where I have to reverse engineer a makefile in order to uninstall!
make install INSTALL_PREFIX=/opt/lzfse
make install INSTALL_PREFIX=$HOME/.../lzfse
rm -r /opt/lzfse
More generally, I believe that uninstalling, upgrading and related operations are the task of a package manager, not a build script.
Alternative: maintain a HUUUUUGE list of xPATH env variables, and update them every time you recompile something and change the directory in the process. Oh, and hope that other people's Makefiles are intelligent enough to not mess up shit (e.g. use headers from system, and library .so files from your own compile)...
I usually set up a Debian chroot with qemu and compile "natively" (e.g. for RPi). It's dog slow, yes, but at least it works reliably in contrast to cross compilation.
The only way I ever got CC to work is with the buildroot toolchain, which has the downside that it isn't Debian.
Why it forgets that? It's not the job of a library build system to install or uninstall things in your system. It's a job for your system's package manager.
Makefile that has a target (historically called "install") that puts things in appropriate places in a chroot-like manner is just good enough.
Moreover, I tend to see "make install" not as actual installation command (that's indeed the task of a package manager), but more of an "extract the relevant build results".
With that in mind, I prefer packages that have a clear "build destination" folder which is filled (and updated) by a plain "make", so that "make install" isn't even needed anymore, because installation then boils down to a trivial "cp -R" command.
This, of course, requires a disciplined separation of intermediate build results from the final build results. But that shouldn't be too hard. In fact, this may be simpler than writing down a good "make install" in the first place.
Sure, you can install each compiled package to its own subdirectory under /usr/local/, but then their binaries are not located in a default PATH. Whether performed accidentally or intentionally, installing to /usr/local/ prefix (/usr/local/bin/, etc.), should not result in having no way of automating an uninstall of those files.
Most of the executions (those actually used in the wild) of this strategy are quite stupid. Add to that the fact that building packages with distribution's tools is quite easy, and now on top of that add fpm, which produces terrible packages and should be banned for upstream maintainers, but for a desktop installation they're perfectly usable, and checkinstall, which is more than fifteen years old.
> Yes, software devs should be providing a Makefile that is friendly for package managers to wrap.
After what I said to steveklabnik (https://news.ycombinator.com/item?id=12014815): build script (whatever it is, it doesn't need to be makefile) should never touch network when building the project and should not expect libraries in any particular place (especially not the directory with the sources nor $HOME/.whatever). This is enough for build script to be friendly towards package managers and none of the package managers expect anything more from the source tarball.
> But the best software provides a Makefile usable on all platforms it supports, without the expectation that a package manager will be involved.
Yes, of course. But package managers really don't expect anything more than a good build script should provide: no network, no hardcoded library paths, only building the artifacts from the locally accessible sources. And maybe a target that puts the artifacts in appropriate places under $DESTDIR, but this is often optional. There's nothing more than one could do by hand, installing stuff into /opt/$someproject directory, so it can be safely removed altogether, and add symlinks to /usr/local/bin, so they're in typical $PATH.
Package managers actually springed from automating what people did manually just before.
> Whether performed accidentally or intentionally, installing to /usr/local/ prefix (/usr/local/bin/, etc.), should not result in having no way of automating an uninstall of those files.
Let's not make the users mentally disabled people. Do we really need to protect them from all their mistakes? What would be next, adding a recycle bin for files removed with `rm'?
OK, I'm somewhat exaggregating here. But where's the line of that protection?
this could make for a cool portmanteau.
More importantly, who tests it? Most developers using e.g. automake or some other generator don't test this, ever. If you package it, you delegate uninstallation to the package manager.
I'd be very leery of actually running this on my system in case it blew away unrelated bits, or versioned bits shared with other packages or package versions, like shared library symlinks or similar.
Granted, pkgconfig is often a good solution for a hairy problem. I was just so very delighted to see such a simple Makefile :)
I remember reading one paper whose conclusion was running SIMD instructions can be bad for power consumption: while you need the processor in a higher power state for longer without, you can keep the SIMD unit powered off.
[Edit: That said, I have no idea how true this is for the modern Intel CPUs yet alone Apple's custom SoCs.]
As expected whenever a project does this, there's already a PR from someone trying to change that.[0]