How to distribute the pre-built perl module and what version of perl am I creating?

Question

This is probably a multi-part question. Background: we have a native (C ++) library, which is part of our application, and we managed to use SWIG to create a Perl wrapper for this library. Now we would like to distribute this perl module as part of our application.

My first question is how should I distribute this module? Is there a standard way for perl batch modules? I know there is ppm for the ActiveState distribution, but I also need to distribute this for Linux systems. I’m not even sure which files are needed for distribution, but I assume that these are pm and so are the files, at least.

My next question is it looks like I might need to create my module project for every perl version I want to support. How do I know for which perl versions I should build? Are there any standard guidelines ... or better yet, a way to create a package that will work with multiple versions of perl?

Sorry if my questions don't make sense - I'm pretty new to compiled modular aspects of perl.

CLARIFICATION: The main compiled source is patented (closed source), so I can’t just send the source code and the corresponding artifacts for the package. I would like, but in this case this will not happen. Thus, I need a reasonable scheme for packing ready-made binaries for my module.

Answer 1

I look at DBD :: Informix, one of the Perl database driver modules that works with DBI (Perl interface interface). The base libraries used to connect to the IBM Informix Dynamic Server (IDS) are proprietary, but the DBD :: Informix code itself is not. I am distributing this code on CPAN, like any other Perl module. People can download this source and (provided that they have the Informix ClientSDK installed on their machine, and Perl and DBI, etc.), they can build DBD :: Informix to work with their installed Perl.

I would strongly advise you to agree that your Perl interface code will be available in its original form, even if the library with which it interacts is the property. This allows people to install code with any version of Perl that they have - without requiring you to deal with inconsistencies.

If you still want to provide binary support, you will need to develop which platforms you want to support and build a module with a standard version of Perl on each such platform. It is getting messy. You need access to an instance of each machine. Of course, virtual machines make this easier, but still inconvenient, and the number of platforms and versions is only growing. But you still need to support people who don't use the standard version of Perl on their machine - so the Perl shell interface must be provided in its original form.

Answer 2

DISCLAIMER: I have no experience creating binary packages that can be easily installed. So I am doing this CW post so that it is easier for others to add their tips.

You must make the distribution available in its original form so that it can be compiled into each system adapted to the specifics of that system. I really like Module :: Build for this purpose.

For ActiveState users on Windows, you probably want to have four or six PPMs based on whether you want to support 5.6 . Pack both 32-bit and 64-bit versions for each of 5.6 , 5.8 and 5.10 . Use the version of mingw that you can install with ppm to compile modules to maintain binary compatibility.

Another option is to use PAR :: Packer and distribute your application in the PAR archive. In this context, PAR :: WebStart may be useful, although I have not tried it. However, I have had success with PAR archives in the past.