Software that doesn't use DESTROOT and funny tarball directories

Watson Ladd watsonbladd at
Tue Jul 19 08:49:49 PDT 2016

On Jul 19, 2016 8:38 AM, "Daniel J. Luke" <dluke at> wrote:
> On Jul 19, 2016, at 8:19 AM, Ryan Schmidt <ryandesign at> 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
> Since most things use autotools, it does (usually) make things easier for
us - but autotools is not great.
> I largely agree with phk (
> And also
> "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.

We've got it building, the problems outstanding are one easy upstream patch
and its tendency to fetch things during build/vendored zlib.

Personally I'm not volunteering to maintain distribution patches to fix the
fetch and zlib issues. It seems upstream won't budge on zlib. (So what?
Everyone vendors SQLite) and I don't know what they think  about avoiding
fetch in build.

If it compiles, installs, uninstalls, and works, I consider that problem
> --
> Daniel J. Luke
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the macports-dev mailing list