Re^2: Check compiler features before building XS module

What module?

Compress::DSRC

Don't exit cleanly , let the compiler try to do its thing

Based on my interpretation of the CPAN Testers FAQ, if Build.PL returns 0 before generating the Build script, it is treated as an incompatible system (similar to unsatisified minimum Perl version, etc) and the test attempt is ignored. It seems to me that if the system doesn't have a compatible compiler, this would be the desired response. This is basically the behavior of Devel::CheckLib as I understand it.

Your system call could easily fail because of shell interpolation, and if you exit, compiler never gets a chance

I definitely don't want to prevent otherwise successful installs, and my solution is probably not ideal. It does still seem, though, like the proper behaviour would be to check for a compatible compiler as a prerequisite and exit as above if none was found. This would make the testing results more meaningful and possibly be helpful to an end-user trying to troubleshoot.

Also %Config

This gives details on how Perl was compiled, correct? That might not be with the same compiler that would be used to build the module, although I could be wrong here.

Comment on Re^2: Check compiler features before building XS module

Replies are listed 'Best First'.
Re^3: Check compiler features before building XS module ( extra_compiler_flags -std=c++11 ) by Anonymous Monk on Jan 04, 2016 at 20:33 UTC
Well, Compress-DSRC-0.002/Build.PL uses Module::Build::WithXSpp which uses ExtUtils::CppGuess It is those modules that need enhancing not your Build.PL, so you can simply tell them you want C++11, without having to use extra_compiler_flags -std=c++11 or ... in your Build.PL But speaking generically, Yes, %Config is where you're supposed to retrieve the compiler name, compiler options..... used to build perl, they're going to be used to build your module as well If a user is going to use a different compiler, hes going to override %Config with ExtUtils::FakeConfig ... Sure, print an extra message to make it easy for user to understand that it probably won't work; compiler messages can be hard to understand But you shouldn't prevent the compiler from trying Only the compiler knows for sure if it supports C++11 Best option is to let the compiler try	[reply]
Re^4: Check compiler features before building XS module ( extra_compiler_flags -std=c++11 ) by jdv (Sexton) on Jan 04, 2016 at 21:24 UTC
Well, Compress-DSRC-0.002/Build.PL uses Module::Build::WithXSpp which uses ExtUtils::CppGuess It is those modules that need enhancing not your Build.PL, so you can simply tell them you want C++11, without having to use extra_compiler_flags -std=c++11 or ... in your Build.PL Definitely, thanks. I'll look into filing a feature request. But you shouldn't prevent the compiler from trying Only the compiler knows for sure if it supports C++11 Best option is to let the compiler try I don't disagree in principle, but in my mind the end result of a failure because of an incompatible compiler should be the same as a failure of other prerequisite checks (Perl version, OS, etc). This goes back to your first point about extending ExtUtils::CppGuess, which seems like the correct longer-term solution.	[reply]
Re^5: Check compiler features before building XS module ( extra_compiler_flags -std=c++11 ) by Anonymous Monk on Jan 04, 2016 at 21:39 UTC
I don't disagree in principle, but in my mind the end result of a failure because of an incompatible compiler should be the same as a failure of other prerequisite checks (Perl version, OS, etc). This goes back to your first point about extending ExtUtils::CppGuess, which seems like the correct longer-term solution. :) Well, for about 15 years now, I've seen these pre-compiler checks fail time after time Having to fight the tools, every enhanced Makefile.PL or new baby is tiresome :D Maybe 15 years from now these pre-compiler checks will be good enough to have final say Perl has always been optimistic, it should always be optimistic, its optimistic to let compiler have final say	[reply]