Software that doesn't use DESTROOT and funny tarball directories
ryandesign at macports.org
Tue Jul 19 08:44:59 PDT 2016
On Jul 19, 2016, at 10:37 AM, Daniel J. Luke wrote:
> On Jul 19, 2016, at 8:19 AM, Ryan Schmidt wrote:
>> This is one of the problems with projects that roll their own nonstandard configure scripts and Makefiles -- they don't work the way anybody unfamiliar with that project expects. Developers would do well to adopt standard configure script and Makefiles made with autotools since everyone already knows how they work and using standardized well-tested tools like autotools avoids problems project developers may not even know exist.
> Since most things use autotools, it does (usually) make things easier for us - but autotools is not great.
> I largely agree with phk (https://www.varnish-cache.org/docs/2.1/phk/autocrap.html).
> And also https://www.reddit.com/r/programming/comments/83pnv/autotools_sucks_that_is_all/c085x1d -
> "Are you seriously suggesting that using M4 to metaprogram a shell script to metaprogram C source code to test for language features in order to metaprogram the final Makefile to build the program in your target language isn't entirely optimal?"
> In any event, part of the whole point of MacPorts is that the maintainer is the only one who has to figure out how to build the project, and after encoding that knowledge into a Portfile, we all benefit.
Without reading those links, I already know autotools sucks, and from the standpoint of a software developer I don't really enjoy writing autotools files. However, from the standpoint of a package maintainer, I love autotools for the consistency and compatibility it affords, assuming the project developers use it correctly are keeping up to date with new versions of autotools. Considering all the various build systems we encounter in MacPorts, from autotools to xcodebuild to cmake to scons to qmake to manually crafted Makefiles, my impression is that autotools sucks the least.
More information about the macports-dev