Skip Menu |
 

This queue is for tickets about the PathTools CPAN distribution.

Report information
The Basics
Id: 74820
Status: open
Priority: 0/
Queue: PathTools

People
Owner: Nobody in particular
Requestors: ribasushi [...] leporine.io
Cc: rt-cpan [...] trout.me.uk
AdminCc:

Bug Information
Severity: Important
Broken in: (no value)
Fixed in: (no value)



CC: rt-cpan [...] trout.me.uk
Subject: The XS part of Cwd ought to be optional
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
X-Mailer: MIME-tools 5.427 (Entity 5.427)
Content-Disposition: inline
Content-Transfer-Encoding: binary
X-RT-Original-Encoding: utf-8
Content-Length: 910
Download (untitled) / with headers
text/plain 910b
There is a number of different "can we build XS" checks available in the wild currently. All of them end up simply relying on ExtUtils::CBuilder->new->has_compiler (with various fallbacks when EU::CB is not available, most of them plain suck). While EU::CB itself properly installs and tests in an environment without a compiler, it depends on a specific version of File::Spec, not available on older perls. In that line of events, File::Spec itself is a pure-perl module, but Cwd has an XS portion, which PathTools insists on building, even though a PP falback is available. As a result if someone with a gcc-less system tries to install a module which configure-requires EU::CB on e.g. perl 5.8.5 using something that does respect configure-requires (e.g. cpanminus) - the installation will ultimately fail, without any clear workarounds. Is it possible to make the lack of XS a soft-failure for PathTools?
MIME-Version: 1.0
X-Mailer: MIME-tools 5.427 (Entity 5.427)
Content-Disposition: inline
Content-Type: text/plain; charset="UTF-8"
Message-ID: <rt-3.8.HEAD-17369-1328799290-1281.74820-0-0 [...] rt.cpan.org>
Content-Transfer-Encoding: binary
X-RT-Original-Encoding: utf-8
Content-Length: 225
Download (untitled) / with headers
text/plain 225b
I support the idea in theory. What I wouldn't want is for the twisty turns of CWD code to get even more complicated as a result, though. It's already pretty yucky. Maybe this is an opportunity to make things tidier? -Ken
From ribasushi [...] cpan.org Thu Feb 9 09: 59:48 2012
CC: rt-cpan [...] trout.me.uk
MIME-Version: 1.0
X-Spam-Status: No, score=-4.197 tagged_above=-99.9 required=10 tests=[AWL=-2.297, BAYES_00=-1.9] autolearn=ham
In-Reply-To: <rt-3.8.HEAD-17369-1328799290-1398.74820-6-0 [...] rt.cpan.org>
X-Spam-Flag: NO
References: <RT-Ticket-74820 [...] rt.cpan.org> <rt-3.8.HEAD-17369-1328799290-1398.74820-6-0 [...] rt.cpan.org>
X-Virus-Scanned: Debian amavisd-new at bestpractical.com
Message-ID: <4F33DF59.3060504 [...] cpan.org>
Content-Type: text/plain; charset=UTF-8; format=flowed
X-RT-Original-Encoding: utf-8
X-Spam-Score: -4.197
Received: from localhost (localhost [127.0.0.1]) by hipster.bestpractical.com (Postfix) with ESMTP id 7529F241627 for <cpan-bug+PathTools [...] hipster.bestpractical.com>; Thu, 9 Feb 2012 09:59:48 -0500 (EST)
Received: from hipster.bestpractical.com ([127.0.0.1]) by localhost (hipster.bestpractical.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EDztJQWhOw5u for <cpan-bug+PathTools [...] hipster.bestpractical.com>; Thu, 9 Feb 2012 09:59:47 -0500 (EST)
Received: from la.mx.develooper.com (x1.develooper.com [207.171.7.70]) by hipster.bestpractical.com (Postfix) with SMTP id D498C241502 for <bug-PathTools [...] rt.cpan.org>; Thu, 9 Feb 2012 09:59:46 -0500 (EST)
Received: (qmail 3206 invoked by uid 103); 9 Feb 2012 14:59:45 -0000
Received: from x16.dev (10.0.100.26) by x1.dev with QMQP; 9 Feb 2012 14:59:45 -0000
Received: from arx.rabbit.us (HELO arx.rabbit.us) (76.244.88.238) by 16.mx.develooper.com (qpsmtpd/0.80/v0.80-19-gf52d165) with ESMTP; Thu, 09 Feb 2012 06:59:43 -0800
Received: from [10.0.13.6] (unknown [10.0.13.6]) by arx.rabbit.us (Postfix) with ESMTP id D55FDD8090; Thu, 9 Feb 2012 09:59:38 -0500 (EST)
Delivered-To: cpan-bug+PathTools [...] hipster.bestpractical.com
User-Agent: Mozilla-Thunderbird 2.0.0.24 (X11/20100328)
Subject: Re: [rt.cpan.org #74820] The XS part of Cwd ought to be optional
Return-Path: <ribasushi [...] cpan.org>
X-Spam-Check-BY: 16.mx.develooper.com
X-Original-To: cpan-bug+PathTools [...] hipster.bestpractical.com
X-RT-Mail-Extension: pathtools
Date: Thu, 09 Feb 2012 15:59:37 +0100
X-Spam-Level:
To: bug-PathTools [...] rt.cpan.org
Content-Transfer-Encoding: 7bit
From: Peter Rabbitson <ribasushi [...] cpan.org>
RT-Message-ID: <rt-3.8.HEAD-17370-1328799589-724.74820-0-0 [...] rt.cpan.org>
Content-Length: 462
Download (untitled) / with headers
text/plain 462b
Ken Williams via RT wrote: Show quoted text
> <URL: https://rt.cpan.org/Ticket/Display.html?id=74820 > > > I support the idea in theory. What I wouldn't want is for the twisty > turns of CWD code to get even more complicated as a result, though. > It's already pretty yucky. Maybe this is an opportunity to make things > tidier? >
This concerns only the build-stage doesn't it? I am not proposing to change anything in Cwd - it already has all the necessary PP fallbacks.
MIME-Version: 1.0
X-Mailer: MIME-tools 5.427 (Entity 5.427)
Content-Disposition: inline
Content-Type: text/plain; charset="UTF-8"
Message-ID: <rt-3.8.HEAD-1148-1328811095-1194.74820-0-0 [...] rt.cpan.org>
Content-Transfer-Encoding: binary
X-RT-Original-Encoding: utf-8
Content-Length: 88
Makes sense to me. We should try to ensure everything builds clean on a gcc-less system.
MIME-Version: 1.0
X-Mailer: MIME-tools 5.427 (Entity 5.427)
Content-Disposition: inline
Content-Type: text/plain; charset="UTF-8"
Message-ID: <rt-3.8.HEAD-17363-1328815497-1269.74820-0-0 [...] rt.cpan.org>
Content-Transfer-Encoding: binary
X-RT-Original-Encoding: utf-8
RT-Send-CC: rt-cpan [...] trout.me.uk
Content-Length: 277
Download (untitled) / with headers
text/plain 277b
So what would be a way forward here? I can furnish a patch to the Makefile.PL of PathTools, which re-implements the latest EU::BC compile check and decides whether to build the .xs. Checking before I dive into this, as there may be more elegant solutions I have not thought of.


This service is sponsored and maintained by Best Practical Solutions and runs on Perl.org infrastructure.

Please report any issues with rt.cpan.org to rt-cpan-admin@bestpractical.com.