Beefy Boxes and Bandwidth Generously Provided by pair Networks
XP is just a number
 
PerlMonks  

Re^3: XS, raspberry pi, and a hundred bucks

by stevieb (Canon)
on Nov 01, 2021 at 17:37 UTC ( #11138306=note: print w/replies, xml ) Need Help??


in reply to Re^2: XS, raspberry pi, and a hundred bucks
in thread XS, raspberry pi, and a hundred bucks

I usually use Inline::C for initial prototypes and quick one-off tests before I write an actual XS module. I never want a user to have to require Inline.

Replies are listed 'Best First'.
Re^4: XS, raspberry pi, and a hundred bucks
by NERDVANA (Pilgrim) on Nov 02, 2021 at 06:10 UTC
    Check out Inline::Module. It lets you develop using Inline and then package it in a way that all the Inline compilation happens during Makefile.PL and then the resulting installed module doesn't require Inline.

    It's a bit of effort to learn, but I got it working in OpenGL::Sandbox, even packaged up with Dist::Zilla!

Re^4: XS, raspberry pi, and a hundred bucks
by perlfan (Vicar) on Nov 02, 2021 at 01:58 UTC
    That seems fair - mind explaining why? I am only asking for my own edification. I've written exactly one XS module on CPAN, and I had a lot of help; but I can say for sure that any use of Inline::C has not been for anything I plan to distribute broadly. That said, the one difference I can see between the 2 is that XS modules are compiled once on install; Inline::C run the risk of being recompiled if the cache goes away - usually at an inopportune time.
      Indeed Inline::C generates an xs distribution, you only have to use it once to bootstrap an xs module

        Hmmm, yes and no. Because I did not find a straight forward way to tell Inline::C NOT to cleanup XS code after successful compilation. From its source code, the cleanup option is in {API} hash which I do not know how to affect. The very round-about way of doing this was to break the compilation by introducing an obvious error in the C code. That would leave the XS file in the build dir. Albeit broken but easily fixable. That's all based on my own experiments as documentation is a bit scarce. It would be a good feature to allow for converting the hidden XS distribution to a stand-alone module in a straight-forward way. (Edit: see Anonymous response below with proper solution)

        On the very serious other hand, NERDVANA mentions Inline::Module (unknown to me a minute ago) which provides exactly this functionality. I have not tried it yet.

        FWIW, this tells Inline::C to place the output binaries to specific directory ("unhiding" it!) - provided output dir exists. BUT I did not manage to tell it to NOT cleanup so that I can use the XS code. So I can only use the binaries. (Edit: same as above edit)

        use Inline C => Config => # dir must already exist! DIRECTORY => 'xxx' ; use Inline 'C'; # perl code ... __END__ __C__ // C code

        bw, bliako

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: note [id://11138306]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others studying the Monastery: (4)
As of 2022-01-16 18:26 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?
    In 2022, my preferred method to securely store passwords is:












    Results (49 votes). Check out past polls.

    Notices?