|Syntactic Confectionery Delight|
Testing a metacpan dist with XS componentsby huck (Parson)
|on Jun 07, 2018 at 22:32 UTC||Need Help??|
huck has asked for the wisdom of the Perl Monks concerning the following question:
I recently wanted to make/test some changes to a module that contained an .xs component. As in the past when i wanted to test a change to a module i download the .tar.gx, (lets call it a.tar.gz) expanded it (tar -xvf a.tar.gz), changed to its directory (cd a/), make backups for diff (mv a.pm a.pm.bak ; mv a.xs a.xs.bak), and ran the makefile (perl Makefile.PL). All is well.
so i made my changes to a.xs, ran make, and ran make test, and all seemed well.
When i did this before with only a perl component i would then test my EXISTING application under the new code via perl -Iblib/lib ~/cvs/repository/app.pl but this did not seem to get my changes. I added a printf to the .xs code, ran make, and tested again. Nope sure didnt get the new .so file. Added an error to the .xs file and the make failed, removed the error and the make passed.
after a little more digging if found i needed to add blib/arch as an inc directory. Now on my ubuntu 14.04 box /usr/local/lib/perl/5.18.2/ has a.pm, and /usr/local/lib/perl/5.18.2/auto/a has a.so which is how I expected make to build my test directory. infact blib/lib/ has an auto and it has an a directory, directory, but all that i found in it was .exists. But instead i find (via playing with make test) the a.so file ends up under blib/arch/auto/a/a.so.
now that i know, i can test with perl -Iblib/lib -Iblib/arch ~/cvs/repository/app.pl, but like i said, it was unexpected. Is this because it was a ExtUtils::MakeMaker Makefile.PL? Or is it just common?
But what i learned most for this excursion was that if you like sausage, never visit a sausage factory.