Make it easy to configure (the build), build, and install #9
Comments
|
I could offer a CMakeLists.txt, I just have to dig it out. |
|
There is no strict requirement to use autotools to have a configure script, as you observe they can be written by hand with a compatible interface. I have another build that doesn't use autotools but I did decide to include a configure script, written by hand. It supports --prefix, DESTDIR, and the usual environment variables. In that build the step is strictly optional, the build works without running it, but if you do run it the build uses the information recorded by the script. I agree having a configure script is a basic expectation, it can be made optional for those who want to continue hand-modifying conf-* files, and there is no strict reason it must be generated by autotools. Since I have a codebase where I concluded the same as @jlmuir here regarding the utility of such a thing, I +1. |
|
From the issues and PRs raised so far, I'd order the list of top impediments to vendor packaging like so:
As a packager, I'd guess other packagers are also accustomed to dealing with exceptions to |
|
There isn't a script requirement for using autotools for other distros like linux & it's variants. If one is building RPM or debian packages, one just have to put the correct command to compile, the correct command to build and the correct command to install the entire binary+config in a staging dirctory defined by DESTDIR env variable. |
It would be great to make it easy to configure (the build), build, and install notqmail. Doing all that by hand is a pain right now. Amitai Schleier has done an excellent job of automating all of that in pkgsrc with the qmail-run package, but obviously that requires using pkgsrc, and I worry that that is a big enough barrier to entry for some people that they won't consider notqmail.
Even though I'm not a big fan of Autotools, being able to do
./configure && make && make installis pretty convenient, and a lot of package management systems support it. If not actually Autotools, it could be an Autotools workalike. (Or something else, I suppose, even though not as standard as the Autotools interface, assuming it requires running just a few commands, would really be a big improvement.)This would also increase the chance of notqmail being included in other OS package repositories (e.g., Homebrew, RHEL, Ubuntu, Arch, Gentoo, Alpine, etc.) which would also be a big plus. It's certainly convenient for someone intending a production deployment, but it's also convenient for someone wishing to try it out.
Lastly, this would make it easier for someone writing a tutorial. There are a number of tutorials on the Internet on how to install and configure software X on operating system Y. For example, DigitalOcean seems to host a number of these (not surprisingly since I assume they hope people will use their services for hosting), and a Google search (e.g.,
how install postfix rhel) will often find them. When a tutorial author can write, e.g., "First, install Postfix:# yum install postfix," that's really easy compared to what they'd have to write without a binary package being available in the OS's package repository.The text was updated successfully, but these errors were encountered: