Re: Lancaster Consensus, deal with PUREPERL_ONLY=0

Am 02.06.2014 um 14:54 schrieb David Golden <[email protected]>:

> On Mon, Jun 2, 2014 at 7:53 AM, Jens Rehsack <[email protected]> wrote:
>> 
>> Am 02.06.2014 um 13:34 schrieb David Golden <[email protected]>:
>> 
>>> On Mon, Jun 2, 2014 at 7:28 AM, Jens Rehsack <[email protected]> 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
>>>> appear".
>>> 
>>> I don't understand what you mean by this.
>> 
>> http://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html
> 
> 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
errors.)

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

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.
> Devel::CheckLib

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 ;)

Cheers
-- 
Jens Rehsack
[email protected]