Software that doesn't use DESTROOT and funny tarball directories

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


On Jul 19, 2016 8:38 AM, "Daniel J. Luke" <dluke at geeklair.net> wrote:
>
> On Jul 19, 2016, at 8:19 AM, Ryan Schmidt <ryandesign at macports.org> 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.

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
solved.
> --
> Daniel J. Luke
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.macosforge.org/pipermail/macports-dev/attachments/20160719/860e3f37/attachment.html>


More information about the macports-dev mailing list