Module::Build::WithXSpp does not correctly handle XS files correctly?

[llancet]

I'm writing a module with XS and C++. After tried XSPP, I found it lack some important functions such as "PPCODE", so I decided to write XS code by my hand.

Though that, the Module::Build::WithXSpp is still very handful, as it automatically find and set C++ flags to compilers, and it calls TypeMap modules automatically. However, when I masked my .xsp files and set up my .xs files, the builder failed to build them into a single .so file. Instead, it compiles the code generated from my .xs files into blib/arch/auto/xs/XXX, and the code automatically generated by M::B::WithXSpp into blib/arch/auto/XXX.

......
cc -shared -L/usr/local/lib -fstack-protector -o blib/arch/auto/xs/Gen
+oEye_Page/GenoEye_Page.so xs/GenoEye_Page.o -lcairo -lstdc++ -lGenoEy
+e -lboost_regex
......
cc -shared -L/usr/local/lib -fstack-protector -o blib/arch/auto/GenoEy
+e/GenoEye.so buildtmp/GenoEye.o -lcairo -lstdc++ -lGenoEye -lboost_re
+gex

As a result, the generated .so file under the correct location is a null one. how could this happen?

This is the layout of my project:

Build  Build.PL  Changes  ignore.txt  MANIFEST
MANIFEST.skip  MYMETA.json  MYMETA.yml  README

lib:
GenoEye.pm

src:
ppport.h

t:
00-load.t  01-page.t  boilerplate.t
manifest.t  pod-coverage.t  pod.t

xs:
GenoEye_Page.c  GenoEye_Page.o
GenoEye_Page.xs  typemap.map

Thanks!!

[Anonymous Monk]

After tried XSPP, I found it lack some important functions such as "PPCODE", so I decided to write XS code by my hand.

http://search.cpan.org/grep?cpanid=MDOOTSON&release=Wx-0.9922&string=PPCODE&i=1&n=1&C=6

Read more... (558 Bytes)

... Though that, the Module::Build::WithXSpp is still very handful, ... how could this happen?

Its really hard to say, anything related to XS really needs the most (reproducibility and minimal test case )dness possible, for example use Inline CPP to call function in so file not working and SOso-0.01.patch.txt

[llancet]

First, to use PPCODE, Wx embeds pure XS in "{% %}". So why don't I write XS code directly?
Second, Wx use ExtUtils::MakeMaker, but not M::B or M::B::WithXSpp.

[Anonymous Monk]

First, to use PPCODE, Wx embeds pure XS in "{% %}". So why don't I write XS code directly?

Because xspp saves you typing because it is "thin" layer over xs?

Second, Wx use ExtUtils::MakeMaker, but not M::B or M::B::WithXSpp.

I don't see how this matters, both call INCLUDE_COMMAND...xspp... which works exactly the same way in both versions

[Anonymous Monk]

ok, I'm back and caffeinated :) If you go to http://p3rl.org/Module::Build::WithXSpp and look at https://metacpan.org/pod/Module::Build::WithXSpp#FEATURES-AND-CONVENTIONS it says

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++.

If Module::Build::WithXSpp detects any XS files in your module, it will skip the generation of this default file and assume that you wrote a custom main XS file.

So I think that answers that

If you go to https://metacpan.org/pod/Module::Build::WithXSpp#JUMP-START-FOR-THE-IMPATIENT it describes the expected layout

So if your module_name is GenoEye (GenoEye.pm) and you have some .xs files (GenoEye_Page.xs) but you don't have GenoEye.xs, then GenoEye.xs (module_name.xs) won't be generated for you (because of GenoEye_Page.xs)

So what you're missing is a GenoEye.xs (module_name.xs) which you need to create , something like WithIntAndString.xs something that uses

INCLUDE_COMMAND: $^X -S xsubpp -- GenoEye_Page.xs

I prefer running examples to reading docs, easier to figure out what docs to read instead of reading all the docs

[llancet]

I looked at the source code of M::B::WithXSpp, and it indeed has a bug. In function ACTION_generate_main_xs:

...
  if (keys(%$xs_files) > 1) {
    # user knows what she's doing, do not generate XS
    $self->log_info("Found custom XS files. Not auto-generating main X
+S file...\n");
    return 1;
  }
...

The HashRef $xs_files contain all user-write XS files, but also contain the auto generated buildtmp/main.xs. And, it tests whether there are more than 1 xs files. This logic causes two issues:

1. If I have only one manually-written XS file, the builder will still auto-generate the main.xs, which is not the expected behavior.

2. If I run the builder, it will generate a main.xs. Thus the builder's behavior will change unexpectedly, as now the XS file amount is changed.

This logic should be revised, and it looks like the plain XS support of M::B::WithXSpp is not extensively tested. Where can I report this issue?

[Anonymous Monk]

... Where can I report this issue?

https://rt.cpan.org/Public/Dist/Display.html?Name=Module-Build-WithXSpp ? or https://metacpan.org/author/SMUELLER ? or bug-Module-Build-WithXSpp#rt.cpan.org ?

[bulk88]

If you were using EUMM, i'd say try putting ".o" files into OBJECT key name for WriteMakefile, but you are not using EUMM. You can also try #xs room on irc.perl.org.