Am 02.06.2014 um 14:54 schrieb David Golden <email@example.com
On Mon, Jun 2, 2014 at 7:53 AM, Jens Rehsack wrote:
Am 02.06.2014 um 13:34 schrieb David Golden <firstname.lastname@example.org
On Mon, Jun 2, 2014 at 7:28 AM, Jens Rehsack wrote:
Others (eg. packagers) have always a compiler and want benefit from XS when
available and what is more important: if the "DEVELOPER MODE FLAGS IS ON",
they want to have a -Werror behavior even for "I enabled foo and it doesn't
I don't understand what you mean by this.
Dude! I know what the compiler flag does! /me hides
I don't understand if you're using "-Werror" as an analogy for how you
want cpan clients to behave or if you mean you want "-Werror" to halt
CPAN installation on error even when a PP fallback is available, or
something else entirely.
I mean: I want a behavior where a user (packager - the one who probably
indirectly invoke "perl Makefile.PL") has a tunable which allows clearly
to express whether
1) PUREPERL is wanted (to create a noarch package)
2) XS is wanted (to create an arch specific package, have the "fastest"
possible installation - whatever)
3) decide on availability
(1) and (2) should really fail when they cannot support that switch
to avoid mistakes. (I'm a fan of the "die early" approach in case of
Generally I fear the "*_ONLY" misleads - I would prefer "--enable-xs"
or "--disable-xs" - but that's a complete different story (and it's
finally not better when the switch itself is unknown).
In my example, if not PUREPERL_ONLY, then if a compiler is present,
compilation works or it fails (possibly due to -Werror), and the
install is halted.
For sure - but I want that the "perl Makefile.PL" dies with error when
PUREPERL_ONLY=0 (or XS_ONLY=1) is set and it's not possible to create
an XS module.
But ... that brings me to another point of view. Take Unix::Statgrab,
File::LibMagic or BSD::Resource as example - they won't work without XS
either. Shall they generally bail-out when PUREPERL_ONLY=1 is set?
Yes and no. Because they don't offer a PP option, PUREPERL_ONLY is
irrelevant to them. They will fail in their "make" stage as usual.
Well - currently there're PP modules which add a dependency for a
corresponding XS module when they find a compiler. Seeing the dependency
picture, it could make sense to fail for File::LibMagic when PP_ONLY
is enabled (and the requiring module falls back to File::MMagic).
A more user-friendly author could probe for a compiler and bail out in
Makefile.PL if one doesn't exist, possibly with one of the CPAN
Testers magic strings like "OS unsupported: need a compiler".
That is what Config::AutoConf->with_xs() should provide. Currently
I have a private one in LMU (not yet pushed), but with an agreement
how to deal with PP_ONLY and how to provide a (however) XS_ONLY I
intend to provide such a check as a public API and every XS module
just should do "C::AC->with_xs()" for compiler and little xs-compile
Web-Search for "CPAN Testers magic strings" doesn't provide suitable
results - is there a list of those magic results?
It's an incorrect and possibly misleading error message, but it will
result in a CPAN Testers report of "NA" instead of "FAIL". The other
option is "exit 0" which will just not send a report at all. E.g.
If I would know what is expected, I will make Config::AutoConf behave.
Devel::CheckLib doesn't work at all - but I don't want to send pull
requests using C::AC until I'm sure that C::AC doesn't introduce
more pitfalls than it solves ;)