Am 02.06.2014 um 14:54 schrieb David Golden <x...@xdg.me>: > On Mon, Jun 2, 2014 at 7:53 AM, Jens Rehsack <rehs...@gmail.com> wrote: >> >> Am 02.06.2014 um 13:34 schrieb David Golden <x...@xdg.me>: >> >>> On Mon, Jun 2, 2014 at 7:28 AM, Jens Rehsack <rehs...@gmail.com> 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 rehs...@gmail.com
