Nick Glencross wrote: > > As mentioned on the list yesterday I started evaluating ffcall > as a way of providing NCI functionality. > > http://www.haible.de/bruno/packages-ffcall.html > > I actually really like the current NCI implementation, although > it suffers from a large nci.c file and all the usable prototypes > need to be specified at compile time in call_list.txt. Over time > as more libraries become supported this list will quickly grow.
Here's a reference to the last time this thread came up: http://groups.google.com/group/perl.perl6.internals/browse_frm/thread/8b1b5e 7e343ce3c4/ and a shortened URL forwarded version: http://ffcall-perl6-internals.notlong.com Here's the tail end: 8. Dan Sugalski Jan 12 2004, 12:49 pm At 10:13 AM -0600 1/12/04, Garrett Goebel wrote: > >Tim Bunce wrote: >> >> I see Dan says in his blog "Yeah, I know, we should use libffi, and >> we may as a fallback, if we don't just give in and build up the >> function headers everywhere." >> >> I'm not familiar with libffi so this may be a dumb question, >> but why the apparent reluctance to use it? > >The reluctance probably doesn't have anything to do with its very liberal >licensing terms... Nope. The two issues were portability and the prospect of a library which isn't ours that we'd need to maintain if we were distributing it. I'm fine with someone taking a stab at teaching Configure to probe for it on platforms that don't have the JIT building up function headers already, and teaching nci.c to use it in that case. (As long as the order of preference is "JIT building functions", "libffi", "current hackish NCI scheme" is maintained) -- Dan 9. Garrett Goebel Jan 12 2004, 1:48 pm Tim Bunce wrote: > > Tim Bunce wrote: > > > > I see Dan says in his blog "Yeah, I know, we should use libffi, > > and we may as a fallback, if we don't just give in and build up > > the function headers everywhere." > > > > I'm not familiar with libffi so this may be a dumb question, > > but why the apparent reluctance to use it? > > > > In http://www.nntp.perl.org/group/perl.perl6.internals/253 I see > Garrett Goebel quotes Bruno Haible saying "I could agree to the > LGPL license. Perl could then use ffcall as a shared library > (linked or via dlopen)" > > And I see http://www.parrotcode.org/docs/faq.pod.html says > "Code accepted into the core interpreter must fall under the same > terms as parrot. Library code (for example the ICU library we're > using for Unicode) we link into the interpreter can be covered by > other licenses so long as their terms don't prohibit this." > > So it seems there's no licensing issue preventing parrot using libffi. > > Is that right? > Are there any others? My bad. In my comments on Dan's blog, I confused libffi with ffcall. Both do roughly the same thing... The libffi was originally produced by Cygnus, but is now part of GCC. http://sources.redhat.com/libffi/ http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libffi/LICENSE ffcall was produced by Bruno Haibel as part of his CLISP package. http://www.haible.de/bruno/packages-ffcall.html ffcall used to be considered more mature/stable, but since libffi was included in GCC the general impression true or not is that libffi is more actively maintained. From mailing lists and csv logs, it looks like both are actively maintained... 10. Tim Bunce Jan 13 2004, 9:49 am And since it seems both are usable for parrot from a licencing perspective we're free to use whichever suits best on a given platform - assuming someone implements the relevant interface code. Tim. -- Garrett Goebel IS Development Specialist ScriptPro Direct: 913.403.5261 5828 Reeds Road Main: 913.384.1008 Mission, KS 66202 Fax: 913.384.2180 www.scriptpro.com garrett at scriptpro dot com
