Module...ithXSpp(3pm)

💖 Module::Build::WithXSpp — the XS++ glow-up of Module::Build

ok so bestie, you found the manual page for Module::Build::WithXSpp, section 3pm, and honestly? it's giving build system but make it C++. let's get into it 🎀

---

✨ NAME ✨

Module::Build::WithXSpp — the XS++ enhanced flavour of Module::Build. periodt. 💅

---

🦋 SYNOPSIS 🦋

In your Build.PL, you literally just do this:

use strict;
use warnings;
use 5.006001;

use Module::Build::WithXSpp;

my $build = Module::Build::WithXSpp->new(
  # normal Module::Build arguments...
  # optional: mix in some extra C typemaps:
  extra_typemap_modules => {
    'ExtUtils::Typemaps::ObjectMap' => '0',
  },
);
$build->create_build_script;

that's it, that's the whole vibe check. 🌸

---

💜 DESCRIPTION 💜

so this is a subclass of Module::Build that adds some tools and processes so wrapping C++ with XS++ (ExtUtils::XSpp) is actually easy instead of a whole emotional journey. 🫶

there are a few minor differences from using Module::Build for a regular ordinary XS module, plus a few conventions you should lowkey know about as an XS++ module author. they're all documented down in the FEATURES AND CONVENTIONS section. but if you can't be bothered to read all that (valid, no judgement ✨), you may choose to skip it and blindly follow the advice in JUMP START FOR THE IMPATIENT. iykyk.

if you want a full distribution based on this build tool, there's an example in the ExtUtils::XSpp distribution under examples/XSpp-Example. using that example as the basis for your own Module::Build::WithXSpp-based distribution is probably a good idea. 💡

---

🌈 FEATURES AND CONVENTIONS 🌈

📂 XS files

by default, Module::Build::WithXSpp will automatically generate a main XS file for your module, which includes all XS++ files and does the correct incantations to support C++. slay, no cap. 🪄

but if Module::Build::WithXSpp detects any XS files in your module, it will skip generating this default file and assume you wrote a custom main XS file. if that is not what you want, and you wish to simply include plain XS code, then you should put the XS in a verbatim block of an .xsp file. and in case you need to use the plain-C part of an XS file for #include directives and other code, then put your code into a header file and #include it from an .xsp file, like this:

In src/mystuff.h:

#include <something>
using namespace some::thing;

In xsp/MyClass.xsp

#include "mystuff.h"

%{
  ... verbatim XS here ...
%}

⚠️ heads up bestie: there is no guarantee about the order in which the XS++ files are picked up. just so you know. 💀

🏗️ Build directory

when building your XS++ based extension, a temporary build directory buildtmp is created for the byproducts. it gets automatically cleaned up by ./Build clean. tidy queen behavior. 🧹✨

🗂️ Source directories

a Perl module distribution typically has the module .pm files in its lib subdirectory. in a Module::Build::WithXSpp based distribution, there are two more such conventions about source directories:

• if any C++ source files are present in the src directory, they will be compiled to object files and linked automatically. 🔥
• any .xs, .xsp, and .xspt files in an xs or xsp subdirectory will be automatically picked up and included by the build system. 🎀

and for backwards compatibility, files of the above types are also recognized in lib. (yes, we're keeping the old ways alive, we respect our elders 💖)

🧬 Typemaps

in XS++, there are two types of typemaps: the ordinary XS typemaps which conventionally go in a file called typemap, and XS++ typemaps.

the ordinary XS typemaps will be found in the main directory, under lib, and in the XS directories (xs and xsp). they are required to carry the .map extension or to be called typemap. you may use multiple .map files if the entries do not collide. they will be merged at build time into a complete typemap file in the temporary build directory. ✨

the extra_typemap_modules option is the preferred way to do XS typemapping, and honestly it's the main character here 👑. it works like any other Module::Build argument that declares dependencies, except that it loads the listed modules at build time and includes their typemaps into the build.

the XS++ typemaps are required to carry the .xspt extension or (for backwards compatibility) to be called typemap.xsp.

🔍 Detecting the C++ compiler

Module::Build::WithXSpp uses ExtUtils::CppGuess to detect a C++ compiler on your system that is compatible with the C compiler that was used to compile your perl binary. it sets some additional compiler/linker options. 🛠️

this is known to work on GCC (Linux, MacOS, Windows, and ?) as well as the MS VC toolchain. patches to enable other compilers are very welcome. 🥺🫶

🔗 Automatic dependencies

Module::Build::WithXSpp automatically adds several dependencies (on the currently running versions) to your distribution. you can disable this by setting auto_configure_requires => 0 in Build.PL.

these are at configure time: Module::Build, Module::Build::WithXSpp itself, and ExtUtils::CppGuess. additionally there will be a build-time dependency on ExtUtils::XSpp. 📦

you do not have to set these dependencies yourself unless you need to set the required versions manually.

📎 Include files

unfortunately, including the perl headers produces quite some pollution and redefinition of common symbols. 😭 therefore, it may be necessary to include some of your headers before including the perl headers. specifically, this is the case for MSVC compilers and the standard library headers.

so if you care about that platform in the least, you should use the early_includes option when creating a Module::Build::WithXSpp object, to list headers to include before the perl headers. if such a supplied header file starts with a double quote, #include "..." is used, otherwise #include <...> is the default. example:

Module::Build::WithXSpp->new(
  early_includes => [qw(
    "mylocalheader.h"
    <mysystemheader.h>
  )]
)

---

🚀 JUMP START FOR THE IMPATIENT 🚀

there are as many ways to start a new CPAN distribution as there are CPAN distributions. choose your favourite (the author just does h2xs -An My::Module), then apply a few changes to your setup:

• obliterate any Makefile.PL. 💀

this is what your Build.PL should look like:

use strict;
use warnings;
use 5.006001;
use Module::Build::WithXSpp;

my $build = Module::Build::WithXSpp->new(
  module_name         => 'My::Module',
  license             => 'perl',
  dist_author         => q{John Doe <john_does_mail_address>},
  dist_version_from   => 'lib/My/Module.pm',
  build_requires => { 'Test::More' => 0, },
  extra_typemap_modules => {
    'ExtUtils::Typemaps::ObjectMap' => '0',
    # ...
  },
);
$build->create_build_script;

if you need to link against some library libfoo, add this to the options:

extra_linker_flags => [qw(-lfoo)],

there is extra_compiler_flags, too, if you need it. ✨

• you create two folders in the main distribution folder: src and xsp. 📁📁
• you put any C++ code that you want to build and include in the module into src/. all the typical C(++) file extensions are recognized and will be compiled to object files and linked into the module. and headers in that folder will be accessible for #include <myheader.h>.

for good measure, move a copy of ppport.h to that directory. see Devel::PPPort. 🫶

• you do not write normal XS files. instead, you write XS++ and put it into the xsp/ folder in files with the .xsp extension. don't worry, you can include verbatim XS blocks in XS++. for details on XS++, see ExtUtils::XSpp. 💅
• if you need to do any XS type mapping, put your typemaps into a .map file in the xsp directory. alternatively, search CPAN for an appropriate typemap module (cf. ExtUtils::Typemaps::Default for an explanation). XS++ typemaps belong into .xspt files in the same directory. 🧬
• in this scheme, lib/ only contains Perl module files (and POD). if you started from a pure-Perl distribution, don't forget to add these magic two lines to your main module:

require XSLoader;
XSLoader::load('My::Module', $VERSION);

---

👀 SEE ALSO 👀

• Module::Build — upon which this module is based.
• ExtUtils::XSpp — implements XS++. the ExtUtils::XSpp distribution contains an examples directory with a usage example of this module. 🎀
• ExtUtils::Typemaps — implements progammatic modification (merging) of C/XS typemaps. ExtUtils::Typemaps was renamed from ExtUtils::Typemap since the original name conflicted with the core typemap file on case-insensitive file systems. 😭
• ExtUtils::Typemaps::Default — explains the concept of having typemaps shipped as modules. 📦
• ExtUtils::Typemaps::ObjectMap — is such a typemap module and probably very useful for any XS++ module. 🔥
• ExtUtils::Typemaps::STL::String — implements simple typemapping for STL std::strings. ✨

---

🫶 AUTHOR 🫶

Steffen Mueller <smueller@cpan.org>

with input and bug fixes from:

• Mattia Barbon
• Shmuel Fomberg
• Florian Schlichting

---

⚖️ COPYRIGHT AND LICENSE ⚖️

Copyright 2010, 2011, 2012, 2013 Steffen Mueller.

This program is free software; you can redistribute it and/or modify it under the same terms as Perl itself.

---

and that's the whole page bestie 💖 this was perl v5.34.0, dated 2022-06-15, and it's the Module...ithXSpp (3pm) manual — go forth and wrap some C++, you absolute icon 👑🌸🦋