3 ms·

Just to reality-proof that: Redis managed to survive 7 years without autotools so far, using similar techniques, you just type "make" regardless of the unix sys

by antirez 10y ago

Just to reality-proof that: Redis managed to survive 7 years without autotools so far, using similar techniques, you just type "make" regardless of the unix system you want to compile Redis with. No major complexity was faced in order to do so, however Redis depends on nothing externally if not libc. For software projects with many external deps it may be worth to use autotools instead.

qznc 10y ago
D is a tiny bit more with two options: `make -f posix.mak` or `make -f win32.mak`.
- antirez 10y ago
  Redis does not have a win32 target, otherwise probably that would be needed as well for simplicity.
sporkenfang 10y ago
People can really easily abuse the Makefile ecosystem and write complicated, difficult to read, spaghetti builds. If something fails somewhere in the m4 macro forest while building on your specific machine, you're hosed for potentially hours or days while trying to figure it out so you can just build the damn project. The whole point of this kind of tooling should be to take some of the heavy lifting out of getting source code built, not add extra complexity to a project. I've been working on and off with Make, C, autoconf, etc for ten years. Maybe if I were a full-time C or C++ person I'd have less trouble with this, but it seems rather excessive. The thing that most discourages me from contributing to certain open source projects is when I clone the repository and the build fails and I can't get the project to build in an hour or less of build-debugging time (and I'm not on a weird setup, I'm on a modern Lenovo with Debian).
cperciva 10y ago
To add another example: spiped is 6 years old and should build on any POSIX system with the Software Development Utilities option, /dev/urandom, and OpenSSL. Over the years I've collected a handful of workarounds for not-quite-POSIX systems, but the "check if we need any workarounds" step of the spiped build is still much faster and simpler than using autotools.
thesmallestcat 10y ago
Quick, how do you install redis to a different prefix? Everybody knows `./configure --prefix=...` (or if they forget, there's `./configure --help`), `make PREFIX=...`, not so much.
- antirez 10y ago
  No way other than "cp redis-server /your/path".
- yellowapple 10y ago
  I've seen quite a bit of "./configure"-less software use "PREFIX=/foo make install" (or some variation thereof) for that (something which I have to address as part of maintaining various Slackbuild scripts). This is usually part of the compilation/installation documentation. If not, install targets are usually simple enough that I can glean which environment variable the Makefile is using to control the installation prefix. Worst case scenario, the SlackBuild I'm writing has to include some call to patch or sed in order to tweak the installation path, or I just have to cp the build output into the package's root directory (something which I'll likely have to do when I get around to updating the CouchDB SlackBuild, but have been putting off since 1.6.x works well enough on Slackware).
derefr 10y ago
This was my own thought when reading the article: how exactly do you use pkg-config to find libs+headers without autotools (or at least an m4 processing step)?
- hp 10y ago
  You can run pkg-config yourself, the m4 macros are just for convenience. Look at the shell the macros expand to to see how to do it. Though I don't see the point in reinventing your own build system, exactly. Some people I trust seem to be getting into Meson these days but I havent tried it.

by antirez 10y ago

qznc 10y ago

D is a tiny bit more with two options: `make -f posix.mak` or `make -f win32.mak`.

antirez 10y ago
Redis does not have a win32 target, otherwise probably that would be needed as well for simplicity.

sporkenfang 10y ago

People can really easily abuse the Makefile ecosystem and write complicated, difficult to read, spaghetti builds. If something fails somewhere in the m4 macro forest while building on your specific machine, you're hosed for potentially hours or days while trying to figure it out so you can just build the damn project. The whole point of this kind of tooling should be to take some of the heavy lifting out of getting source code built, not add extra complexity to a project. I've been working on and off with Make, C, autoconf, etc for ten years. Maybe if I were a full-time C or C++ person I'd have less trouble with this, but it seems rather excessive. The thing that most discourages me from contributing to certain open source projects is when I clone the repository and the build fails and I can't get the project to build in an hour or less of build-debugging time (and I'm not on a weird setup, I'm on a modern Lenovo with Debian).

cperciva 10y ago

To add another example: spiped is 6 years old and should build on any POSIX system with the Software Development Utilities option, /dev/urandom, and OpenSSL. Over the years I've collected a handful of workarounds for not-quite-POSIX systems, but the "check if we need any workarounds" step of the spiped build is still much faster and simpler than using autotools.

thesmallestcat 10y ago

Quick, how do you install redis to a different prefix? Everybody knows `./configure --prefix=...` (or if they forget, there's `./configure --help`), `make PREFIX=...`, not so much.

antirez 10y ago
No way other than "cp redis-server /your/path".
yellowapple 10y ago
I've seen quite a bit of "./configure"-less software use "PREFIX=/foo make install" (or some variation thereof) for that (something which I have to address as part of maintaining various Slackbuild scripts). This is usually part of the compilation/installation documentation. If not, install targets are usually simple enough that I can glean which environment variable the Makefile is using to control the installation prefix. Worst case scenario, the SlackBuild I'm writing has to include some call to patch or sed in order to tweak the installation path, or I just have to cp the build output into the package's root directory (something which I'll likely have to do when I get around to updating the CouchDB SlackBuild, but have been putting off since 1.6.x works well enough on Slackware).

derefr 10y ago

This was my own thought when reading the article: how exactly do you use pkg-config to find libs+headers without autotools (or at least an m4 processing step)?

hp 10y ago
You can run pkg-config yourself, the m4 macros are just for convenience. Look at the shell the macros expand to to see how to do it. Though I don't see the point in reinventing your own build system, exactly. Some people I trust seem to be getting into Meson these days but I havent tried it.