Good luck with getting pkg-config to recognize your include files automatically, for example. Or the good old "man" utility.
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)...
If you are alluding to cross-compiling, rest assured that I wrote my comment being fully aware of the plenty of pitfalls, which is why I started the MXE (mingw-cross-env) project some time ago:
Cross-compiling is yet another pile of dungheap in addition to the dungheap I mentioned.
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.
> Yet it forgets the MOST important thing: make uninstall.
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.
This disregards a common use of the Makefile: compiling software from source, bypassing the use of a package manager in the first place. Yes, software devs should be providing a Makefile that is friendly for package managers to wrap. But the best software provides a Makefile usable on all platforms it supports, without the expectation that a package manager will be involved.
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.
> This disregards a common use of the Makefile: compiling software from source, bypassing the use of a package manager in the first place.
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?
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.
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!