On 28 December 2015 at 13:20, Joshua Root wrote: > On 2015-12-28 19:54 , Mojca Miklavec wrote: >> Hi, >> >> I wonder if there is any special reason for this weird packaging of >> libffi (the include files in particular; does it conflicts with other >> libraries?): >> >> Port libffi contains: >> /opt/local/lib/libffi-3.2.1/include/ffi.h >> /opt/local/lib/libffi-3.2.1/include/ffitarget.h >> /opt/local/lib/libffi.6.dylib >> /opt/local/lib/libffi.a >> /opt/local/lib/libffi.dylib >> /opt/local/lib/libffi.la >> /opt/local/lib/pkgconfig/libffi.pc >> /opt/local/share/info/libffi.info >> /opt/local/share/man/man3/ffi.3.gz >> /opt/local/share/man/man3/ffi_call.3.gz >> /opt/local/share/man/man3/ffi_prep_cif.3.gz >> /opt/local/share/man/man3/ffi_prep_cif_var.3.gz >> >> When building moarvm which needs ffi.h and apparently doesn't care >> about "libffi.pc" yet, I had to add the following to the Portfile >> which looks like a relatively bad idea to me: >> >> configure.cflags-append "-I${prefix}/lib/libffi-3.2.1/include" > > I guess you mean it's a bad idea because of the hardcoded version? This > isn't a bad construct in general, apart from that (though normally > cppflags is more appropriate). It's better to use pkgconfig of course.
Other than the hardcoded version number I wonder what the header files do under "lib". On 28 December 2015 at 13:58, Ryan Schmidt wrote: > >> Can someone suggest me what to do (other than asking moarvm >> maintainers to fix the libffi detection and use)? > > Look at some of the other portfiles that use libffi, which call pkg-config in > a pre-configure block so as not to hardcore the path or version information > in the portfile. Or, if you can, modify the build system to use pkg-config > directly, then send the patch to the developers. Pre-configure block sounds reasonable. I'll try to reach the upstream "users" of libffi as well as possible the libffi developers (I need to inspect the situation a bit first). In the meantime I figured out that libffi looks like an alternative to dyncall (in the context of MoarVM), so maybe I won't need that number after all, but I need some time to sort it all out. Mojca _______________________________________________ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev