libffi's weird packaging

[Mojca Miklavec]

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