Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

document bundle interface #168

Merged
merged 3 commits into from Aug 13, 2019

Conversation

@plicease
Copy link
Member

commented Aug 11, 2019

Documentation reads when rendered:

NAME

FFI::Platypus::Bundle - Bundle foreign code with your Perl module

VERSION

version 0.95_06

SYNOPSIS

ffi/foo.c:

#include <ffi_platypus_bundle.h>
#include <string.h>

typedef struct {
  char *name;
  int value;
} foo_t;

foo_t*
foo__new(const char *class_name, const char *name, int value)
{
  (void)class_name;
  foo_t *self = malloc( sizeof( foo_t ) );
  self->name = strdup(name);
  self->value = value;
  return self;
}

const char *
foo__name(foo_t *self)
{
  return self->name;
}

int
foo__value(foo_t *self)
{
  return self->value;
}

void
foo__DESTROY(foo_t *self)
{
  free(self->name);
  free(self);
}

lib/Foo.pm:

package Foo;

use strict;
use warnings;
use FFI::Platypus;

{
  my $ffi = FFI::Platypus->new( api => 1 );

  $ffi->type('object(Foo)' => 'foo_t');
  $ffi->mangler(sub {
    my $name = shift;
    $name =~ s/^/foo__/;
    $name;
  });

  $ffi->bundle;

  $ffi->attach( new =>     [ 'string', 'string', 'int' ] => 'foo_t'  );
  $ffi->attach( name =>    [ 'foo_t' ]                   => 'string' );
  $ffi->attach( value =>   [ 'foo_t' ]                   => 'int'    );
  $ffi->attach( DESTROY => [ 'foo_t' ]                   => 'void'   );
}

1;

t/foo.t

use Test::More;
use Foo;

my $foo = Foo->new("platypus", 10);
isa_ok $foo, 'Foo';
is $foo->name, "platypus";
is $foo->value, 10;

done_testing;

Makefile.PL:

use ExtUtils::MakeMaker;
use FFI::Build::MM;
my $fbmm = FFI::Build::MM->new;
WriteMakefile(
  $fbmm->mm_args(
    NAME     => 'Foo',
    DISTNAME => 'Foo',
    VERSION  => '1.00',
    # ...
  )
);

sub MY::postamble
{
  $fbmm->mm_postamble;
}

or dist.ini:

name    = Foo
version = 0.01
...

[FFI::Build]
[PruneFiles]
filename = fbx.json
match    = ^ffi/_build/

DESCRIPTION

This document serves as a tutorial for using the new bundling interface provided
by FFI::Platypus as of api version 1. It requires FFI::Platypus of at least
1.00.

Sometimes when writing FFI bindings you need to include a little C code (or your
favorite compiled language) to finish things off. Alternatively, you might just
want to write some C code (or your favorite compiled language) to include with your
Perl module to make a tight loop faster. The bundling interface has you covered.

Basic example

To illustrate we will go through the files in the synopsis and explain
how and why they work. To start with we have some C code which emulates object
oriented code using foo__ as a prefix. We use a C struct that we call
foo_t to store our object data. On the C level the struct acts as a class,
when combined with its functions that act as methods. The constructor just
allocates the memory it needs for the foo_t instance, fills in the
appropriate fields and returns the pointer:

foo_t*
foo__new(const char *class_name, const char *name, int value)
{
  (void) class_name;
  foo_t *self = malloc( sizeof( foo_t ) );
  self->name = strdup(name);
  self->value = value;
  return self;
}

We include a class name as the first argument, because Perl will include that
when calling the constructor, but we do not use it here. An exercise for the
reader would be to add hierarchical inheritance.

There are also some methods which return member values. This class has only
read only members, but you could have read/write or other methods depending
on your needs.

const char *
foo__name(foo_t *self)
{
  return self->name;
}

We also include a destructor so that the memory owned by the object can be
freed when it is no longer needed.

void
foo__DESTROY(foo_t *self)
{
  free(self->name);
  free(self);
}

This might start to look a little like a Perl module, and when we look at the Perl
code that binds to this code, you will see why. First lets prepare the
FFI::Platypus instance and specify the correct api version:

my $ffi = FFI::Platypus->new( api => 1 );

The bundle interface is only supported with api version 1, so if you try to use
version 0 it will not work. Next we define an object type for foo_t which will
associate it with the Perl class Foo.

$ffi->type('object(Foo)' => 'foo_t');

As object type is a blessed reference to an opaque (default) or integer type which
can be used as a Perl object. Platypus does the translating of Perl object to and
from the foo_t pointers that the C code understands. For more details on Platypus
types see FFI::Platypus::Type.

Next we set the mangler on the Platypus instance so that we can refer to function
names without the foo__ prefix. You could just not use the prefix in your C
code and skip this step, or you could refer to the function names in their full
in your Perl code, however, this saves extra typing and allows you to bundle more
than one class with your Perl code without having to worry about name conflicts.

$ffi->mangler(sub {
  my $name = shift;
  $name =~ s/^/foo__/;
  $name;
});

Finally we let Platypus know that we will be bundling code.

$ffi->bundle;

By default, this searches for the appropriate place for your dynamic libraries using
the current package. In some cases you may need to override this, for example if your
dist is named Foo-Bar but your specific class is named Foo::Bar::Baz, you'd
want something like this:

package Foo::Bar::Baz;
use FFI::Platypus;
my $ffi = FFI::Platypus->new( api => 1 );
$ffi->bundle('Foo::Bar');
...

Now, finally we can attach the methods for our class:

$ffi->attach( new =>     [ 'string', 'int' ] => 'foo_t'  );
$ffi->attach( name =>    [ 'foo_t' ]         => 'string' );
$ffi->attach( value =>   [ 'foo_t' ]         => 'int'    );
$ffi->attach( DESTROY => [ 'foo_t' ]         => 'void'   );

Note that we do not have to include the foo__ prefix because of the way we set up
the mangler. If we hadn't done that then we could instead attach with the full names:

$ffi->attach( [ 'foo__new'  => 'new' ]  => [ 'string', 'int' ] => 'foo_t'  );
$ffi->attach( [ 'foo__name' => 'name' ] => [ 'foo_t' ]         => 'string' );
...

You're done! You can now use this class. Lets write a test to make sure it works,

use strict;
use warnings;
use Test::More;
use Foo;

my $foo = Foo->new("platypus", 10);
isa_ok $foo, 'Foo';
is $foo->name, "platypus";
is $foo->value, 10;

done_testing;

and use prove to check that it works:

% prove -lvm
t/foo.t ..
ok 1 - An object of class 'Foo' isa 'Foo'
ok 2
ok 3
1..3
ok
All tests successful.
Files=1, Tests=3,  0 wallclock secs ( 0.02 usr  0.00 sys +  0.14 cusr  0.03 csys =  0.19 CPU)
Result: PASS

Platypus automatically compiles and links the dynamic library for you:

% ls ffi/_build
foo.c.o  libFoo.so

The C code will be rebuilt next time if the source code is newer than the object or dynamic libraries
files. If the source files are not changed, then it won't be rebuilt to save time. If you are using
the code without MakeMaker, or another build system you are responsible for cleaning up these files.
This is intended as a convenience to allow you to test your code without having to invoke MakeMaker,
or dzil or whatever build system you are using.

When you distribute your module though, you will want the dynamic library built just once
at build-time and installed correctly so that it can be found at run-time. You don't need
to make any changes to your C or Perl code, but you do need to tell MakeMaker to build and
install the appropriate files using FFI::Build::MM:

use ExtUtils::MakeMaker;
use FFI::Build::MM;
my $fbmm = FFI::Build::MM->new;
WriteMakefile(
  $fbmm->mm_args(
    NAME     => 'Foo',
    DISTNAME => 'Foo',
    VERSION  => '1.00',
    # ...
  )
);

sub MY::postamble
{
  $fbmm->mm_postamble;
}

And we can invoke all the normal MakeMaker style stuff and our C code will be compiled, linked
and installed at the appropriate steps.

% perl Makefile.PL
Generating a Unix-style Makefile
Writing Makefile for Foo
Writing MYMETA.yml and MYMETA.json
% make
cp lib/Foo.pm blib/lib/Foo.pm
"/Users/ollisg/perl5/perlbrew/perls/perl-5.30.0/bin/perl" -MFFI::Build::MM=cmd -e fbx_build
CC ffi/foo.c
LD blib/lib/auto/share/dist/Foo/lib/libFoo.dylib
% make test
"/Users/ollisg/perl5/perlbrew/perls/perl-5.30.0/bin/perl" -MFFI::Build::MM=cmd -e fbx_build
"/Users/ollisg/perl5/perlbrew/perls/perl-5.30.0/bin/perl" -MFFI::Build::MM=cmd -e fbx_test
PERL_DL_NONLAZY=1 "/Users/ollisg/perl5/perlbrew/perls/perl-5.30.0/bin/perl" "-MExtUtils::Command::MM" "-MTest::Harness" "-e" "undef *Test::Harness::Switches; test_harness(0, 'blib/lib', 'blib/arch')" t/*.t
t/foo.t .. ok
All tests successful.
Files=1, Tests=3,  0 wallclock secs ( 0.01 usr  0.00 sys +  0.06 cusr  0.01 csys =  0.08 CPU)
Result: PASS

If the Makefile.PL file above looks overly complicated, you can use the
Dist::Zilla::Plugin::FFI::Build plugin to simplify your life if you are
using Dist::Zilla:

[FFI::Build]
[PruneFiles]
filename = fbx.json
match    = ^ffi/_build/

The above incantation for Dist::Zilla::Plugin::PruneFiles will clean up
any files that are built using prove, etc. outside of MakeMaker.

plicease added some commits Aug 11, 2019

@plicease plicease merged commit 723db17 into master Aug 13, 2019

5 checks passed

continuous-integration/appveyor/branch AppVeyor build succeeded
Details
continuous-integration/appveyor/pr AppVeyor build succeeded
Details
continuous-integration/travis-ci/pr The Travis CI build passed
Details
continuous-integration/travis-ci/push The Travis CI build passed
Details
main Task Summary
Details

@plicease plicease deleted the graham/bundle-doco branch Aug 13, 2019

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
1 participant
You can’t perform that action at this time.