3 ms·
I will write this rant here because it will get a bigger audience than any blog I would have. Speaking of someone who occasionally ports software to less commo
by liveoneggs 10y ago
I will write this rant here because it will get a bigger audience than any blog I would have.
Speaking of someone who occasionally ports software to less common environments I have a few things to say that I was hoping to find in this article.
First the case for and against autotools:
autotools are well supported by every packaging system out there (freebsd ports, pkgsrc, apt, rpm, etc) where it's really just a line or three to do the build in the package definition.
The main things that are not usually thought about by developers but are loved by porters and packagers (and come out of the box with autotools) are: DESTDIR support (installing into an intermediate path, so DESTDIR/PREFIX/usr/bin/myapp) and cross-compilation, which is one of the biggest strengths of using C in the first place!
The biggest argument against autotools is that feature discovery at build time is complete bullshit. I hate it. It reduces determinism and ties execution environment to the build environment.
So if you can support DESTDIR and cross compilation without autotools, go for it! It's not that much extra work!
---
The second point I was hoping this article would address is project layout. In the last few years a nice, standard-ish layout for portable projects has emerged but package maintainers end up having to teach it to every new (big) project.
Here are examples where it has gone okay:
https://github.com/nodejs/node/tree/63243bcb330408d511b3945c53719425d8b7abb8/deps/uv/src/unix https://github.com/nodejs/node/tree/63243bcb330408d511b3945c...
https://github.com/golang/go/tree/964639cc338db650ccadeafb7424bc8ebb2c0f6c/src/net https://github.com/golang/go/tree/964639cc338db650ccadeafb74...
Where you are writing to non-portable parts of unix you can build non-portable stuff into their own files named simply after the platforms and include the correct stuff higher up in a .h
and an exmaple of it not going so well:
https://github.com/dart-lang/sdk/issues/10260 https://github.com/dart-lang/sdk/issues/10260
(fwiw you can find https://github.com/mulander https://github.com/mulander all over this "teaching" effort, so points to him)
- iainmerrick 10y agoTotally agreed about autotools. It's fine (if very slow) when it works, when it doesn't work right away it's a massive pain. Sometimes I need to build C code for iOS and Android. Libraries with a nice clean setup like the author of this article describes are great. Libraries that use autotools are more trouble than they're worth.