frazap has asked for the wisdom of the Perl Monks concerning the following question:

I have seen Distro with multiple XS modules that the question has already been asked but I hope to get more specific tips.

I have one very small module, Win32::Shortkeys::Kbh that use xs code to interact with windows API functions.

I can change the code, compile it with a makefile.PL in the top module folder:

WriteMakefile( NAME => 'Win32::Shortkeys::Kbh', VERSION_FROM => 'lib/Win32/Shortkeys/Kbh.pm', ABSTRACT_FROM => 'lib/Win32/Shortkeys/Kbh.pm', OBJECT => 'hook.o Kbh.o', );
The xs c and h files are also in this folder.

I have an other module Win32::Shortkeys, that use this first one and consists only from perl code. The makefile.pl is

WriteMakefile( NAME => 'Win32::Shortkeys', VERSION_FROM => 'lib/Win32/Shortkeys.pm', # finds \$VERSION .... PREREQ_PM => { ... 'Win32::Shortkeys::Kbh' => 0.01, 'Config::YAML::Tiny' => 1.42, ... }, );

Even if the xs module could be used by others, it's so tiny that I would try to unite both modules in a single module (win32::Shortkeys).

I suppose I could place the xs code in a xs folder. From the mod_perl example given in the node above, I see that there's also a makefile.PL here but I would be glad if someone could gave me more indication, redirect me to more examples, before I start testing...

Thanks !

frazap

Replies are listed 'Best First'.
Re: xs code in a perl module
by stevieb (Canon) on Oct 25, 2017 at 15:07 UTC

    I'd recommend against doing this. If others are already (or eventually will) use the XS module but don't need the functionality from the one you propose to encompass it by, then they are two distinct distributions. One just so happens to use the other. What happens if you realize you want another small XS distribution... will you bundle that as well? Now people who want the first small library have to install a distribution with even more code they don't need.

    I have several examples of this sort of thing. I put all of the dissimilar/separate XS code into their own distributions, then require it in higher-level distributions. That allows anyone to use X::Y; and use X::Z; without requiring them to use X; that may have brought in X::A through X::X, which contain functionality they have no need for.

    For example, my RPi::WiringPi distribution pulls in 10 or so XS distributions (eg: RPi::I2C, RPi::SPI, RPi::DHT11). Instead of forcing users to install a whole crapload of distributions they don't need by forcing them to install the top-level one (which takes a relatively significant time to build on the platform it was designed for), they can just install individual components if that's all they need (SPI for example). There are benefits to installing the whole shebang, but that's only if you're going to use multiple pieces of the functionality.

    If the two distributions can be used independently from one another (in your case it sounds like there are benefits to using them independently), they should, imho, remain separate.

      Well thanks. I will keep them separate.

      Now since I have done a some testing I 've found a way that works to get the xs files in the same hierarchy, here it is for the reccord:

      the makefile.pl in the main folder is unchanged except for the added parameter to WriteMakefile

       DIR => [qw(xs)], In the xs folder I have all the *.h, *.c, *.xs. typemap files.

      xs/readme.pl is

      WriteMakefile( NAME => 'Win32::Shortkeys::Kbh', OBJECT => 'hook.o Kbh.o', INC => '-I.'
      and the Win32/Shortkeys/Kbh.pm file is in the lib tree above this xs folder.

      I can use makefile mantra from the main folder to compile, test, and it works.

Re: xs code in a perl module
by holli (Abbot) on Oct 25, 2017 at 12:34 UTC
    Looks like Inline::C is what you are looking for.


    holli

    You can lead your users to water, but alas, you cannot drown them.
Re: xs code in a perl module
by Anonymous Monk on Oct 25, 2017 at 12:39 UTC
    Youve confused module (package associated with a .pm file) with module distribution (tarball/dirtree), All you need to do is merge one tree into the other (.pm .xs .pod .h .c) and copy the prerequisites list into Write/Makefile.PL
      And ditch the object argument youre doing wrong(hardcoding filenames) what makemaker will do automatically
        Well in fact if I remove the line it does not compile. Probably because of hook.c beeing not used/seen.
Re: xs code in a perl module
by Anonymous Monk on Oct 25, 2017 at 12:54 UTC
    You might be able to do this, but you are quite-frankly just making trouble for yourself – and for your colleagues who will eventually maintain the code – by doing something merely because it "tastes better" to you. There is no technical return-on-investment to compensate for the added uncertainty and complexity. "Some files are big, some files are small, and who cares." Just get it to work, in the simplest and most-conventional way possible, and move on to your next task.