Am 02.06.2014 um 01:25 schrieb Karen Etheridge <p...@froods.org>: > On Sun, Jun 01, 2014 at 08:40:14PM +0200, Jens Rehsack wrote: >>> Let me rephrase: making available a "XS-only" choice, when both PP ans XS >>> are >>> available is a mistake. Not just making the choice is a mistake, >>> *presenting it* is a mistake in its own right. >> >> You should explain why that should be a mistake when presenting a "PP-only" >> choice is not a mistake. That doesn't make any sense to me. > > There exists installations that can run PP dists, but not XS dists. > There is no such thing as an installation that *cannot* run a PP > implementation. > > The "give me only the PP version, even if XS is available and installable > on my system" choice is useful when preparing a fatpacked installation. I > do not see any gain in specifying "give me XS or give me death". Not every > dist is XS-based, so is not going to work out in most cases, anyway.
I expected exactly that argument - "we do FatPacking, so it's important". Not everyone does fat packing - there're a lot of use cases out there who manage large build farms and package (with very strange toolchains here and there) compiled distributions. 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". In complex infrastructure (and CPAN is such a one), you'll never be able to detect configuration/build issues otherwise. > I'm wondering why it isn't always possible to split a dist into two > implementations, one PP and the other with XS optimizations. If the dist > simply cannot be implemented using pure Perl (Moose, for example), then > surely the right thing to is simply refuse to install on PP systems? Eg. LMU - you cannot split out LMU::XS for historical reasons. > Can you clarify what the usecases are here? That is, /achieve? Given, a user knows it's system can provide all infrastructure for XS. And some modules always provide just PP, even if they shouldn't. To help digging, bail out when XS check fails will help that type of user. I'm sorry when I appear evangelizing - for me it feels last years that most of p5 walks only in direction "very fast x86 linux farms for horizontal scaling". This might be the loudest use-case - but not the only one. A lot of my customers tell me (during coffee break or similar): "We don't write on public mailing lists or query for support for particular stuff. When it doesn't work or requires to much effort, we use something else." The primary question is: do we want large system management staff's in big industry walking to Maven because we think "user shall be able to control the fulfillment of his/her wish" is not a valid use-case or we don't see why? General (Unix) assumption is: the operator/administrator is god. They know what they're doing and it's on the tools to provide the ability, not to limit. For me the limitation to either have pureperl or maybe more is a to strong limitation. Query is now: do we (as perl community) want a common way to remove that limitation or do I as I mean? I'm fine with "Jens' distribution have a non-standard switch", but I would prefer a "Toolchain community favors that knob to be used". Cheers -- Jens Rehsack rehs...@gmail.com
