On Jul 19, 2016 8:38 AM, "Daniel J. Luke" <dl...@geeklair.net> wrote: > > On Jul 19, 2016, at 8:19 AM, Ryan Schmidt <ryandes...@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 > > >
_______________________________________________ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
