On 27/04/2012 00:40, Marvin Humphrey wrote:
The Clownfish header language currently supports such a feature in its parcel
declarations:
parcel KinoSearch cnick Kino;
OK, I wasn't aware of that feature.
In WhitespaceTokenizer.cfh I had to add a __C__ block that includes
Lucy/Analysis/Inversion.h because the generated XS needs the LUCY_INVERSION
VTable. That's not ideal.
Agreed. IMO what it should look like instead is either something like this...
parcel WhitespaceTokenizer;
use Lucy::Analysis::Tokenizer from org::apache::lucy::Lucy v0.4;
... or like this:
parcel WhitespaceTokenizer;
use org::apache::lucy::Lucy v0.4;
The latter option of "using" whole parcels should be enough for a start.
There's an intricate problem with XSLoader that only manifests when running
the tests. See the comment in WhitespaceTokenizer.pm.
Sheesh, how goofy. I hope we find a fix for that eventually, so that
nobody else has to go down the lengthy debugging path you must have gone down.
The source of the problem is that XSLoader tries to find the library
file by working backwards from the filename of the Perl module. For
example, when testing Lucy, the Perl module is in blib/lib/Lucy.pm.
XSLoader ends up looking for the library in blib/lib/auto/Lucy/Lucy.so
(on Linux) which should be blib/arch/auto/Lucy/Lucy.so.
The only solution I see is to stage Lucy.pm in blib/arch instead of
blib/lib. But that's something Module::Build does for us at the moment.
Here are the two tweaks I had to make to build and pass tests on OS X:
* Hack in a Clownfish include directory manually for when Clownfish::CFC and
Lucy are not installed into $Config{installsitearch}.
* Comment out the "extra_linker_flags" argument in Build.PL.
On OS X, you get this error with you try to link against Lucy.bundle:
ld: in
/Users/marvin/Desktop/scratchlib/lib/perl5/darwin-2level/auto/Lucy/Lucy.bundle,
can't link with bundle (MH_BUNDLE) only dylibs (MH_DYLIB)
collect2: ld returned 1 exit status
Here's the explanation:
http://stackoverflow.com/questions/2339679/what-are-the-differences-between-so-and-dylib-on-osx
One Mach-O feature that hits many people by surprise is the distinction
between shared libraries and dynamically loadable modules. On ELF systems
both are the same; any piece of shared code can be used as a library and
for dynamic loading.
So we should use $Config{so} instead of $Config{dlext}.
This leads me to question whether extensions should be linking against the
shared objects of their dependencies on *any* platform. Does that create a
tight binding that will e.g. break WhitespaceTokenizer when Lucy gets updated?
I'm pretty sure we want runtime relocation of upstream symbols.
On Linux I had to link against Lucy.so. Otherwise I get "undefined
symbol" errors when running the tests.
Nick
