On Fri, Aug 09, 2013 at 09:42:00AM -0400, Chris Marshall wrote:
> This breaks for cygwin since it does run on a windows
> OS so you will find all of windows there---however, if
> you check for "can this platform do unix" then cygwin
> pretty much builds most unix/linux packages.
FWIW, Devel::Asse
I usually consider the ASperl and Strawberry perl the
native windows perls and, cygwin falls into the list of
unix perls...
Except, for external bindings, where the package
configuration might "check for windows first" and
abort or do some win32 stuff.
This breaks for cygwin since it does run on
and for "windows" is meant Strawberry, Activestate, Cygwin, or other?
On Thu, Aug 8, 2013 at 4:18 PM, Paul LeoNerd wrote:
> On Thu, 8 Aug 2013 21:21:39 +0200
> Leon Timmermans wrote:
>
>> On Thu, Aug 8, 2013 at 9:16 PM, Aristotle Pagaltzis
>> wrote:
>> > Yeah, that’ll work great until the moment someone supports three
>> > OSes. Or supports all OSes except a speci
On Thu, 8 Aug 2013 21:21:39 +0200
Leon Timmermans wrote:
> On Thu, Aug 8, 2013 at 9:16 PM, Aristotle Pagaltzis
> wrote:
> > Yeah, that’ll work great until the moment someone supports three
> > OSes. Or supports all OSes except a specific one.
> > (Alien::NotVMS::FooBar?)
>
> Or only recent vers
Agreed, that idea doesn't work. I think the proposed
improved "best effort" docs and FAIL if the Alien::XXX
could not detect or install then configure XXX is a better
approach.
Thanks for the reply,
Chris
On Thu, Aug 8, 2013 at 3:16 PM, Aristotle Pagaltzis wrote:
> * Chris Marshall [2013-08-0
On Thu, Aug 8, 2013 at 9:16 PM, Aristotle Pagaltzis wrote:
> Yeah, that’ll work great until the moment someone supports three OSes.
> Or supports all OSes except a specific one. (Alien::NotVMS::FooBar?)
Or only recent versions of an OS…
Leon
* Chris Marshall [2013-08-04 17:35]:
> Maybe it would be useful to carve out OS specific packages under the
> Alien:: moniker. What about Alien::Unix::libtermkey ?
Yeah, that’ll work great until the moment someone supports three OSes.
Or supports all OSes except a specific one. (Alien::NotVMS::Fo
On Thu, Aug 8, 2013 at 7:43 AM, Paul LeoNerd wrote:
> On Thu, 8 Aug 2013 07:00:07 -0400
> Chris Marshall wrote:
>
>> To the original proposal, I've added the
>> following thoughts:
>>
>> - make test in Alien::XXX should be
>> FAIL if it was not possible to either
>> detect/configure an existi
On Thu, 8 Aug 2013 07:00:07 -0400
Chris Marshall wrote:
> To the original proposal, I've added the
> following thoughts:
>
> - make test in Alien::XXX should be
> FAIL if it was not possible to either
> detect/configure an existing XXX or
> to install a new copy. (This is
> different th
I think the line should be drawn at my
original proposal (document platforms
where the Alien::XXX works or doesn't
work, and add detect/configure/use a
pre-installed XXX rather than have the
default action be a forced install).
The idea is to simplify the process of
writing a useful Alien module f
On Thu, 8 Aug 2013 00:51:37 +0200
Leon Timmermans wrote:
> Sounds like an Alien::libtool may be useful ;-)
Well, where do we draw the line? Alien::GNUmake? Alien::GCC?
We can't supply a new C compiler just for building XS extensions,
because it has to be the same C compiler as the one that buil
On Sun, Aug 4, 2013 at 5:38 PM, Paul LeoNerd wrote:
> Having a look more in detail at why, though, is revealing:
>
> For example:
>
> http://www.cpantesters.org/cpan/report/754b7df1-6c93-1014-b350-ae488c0ce015
>
> gives:
>
>
> # running Build.PL
> 'make' is not recognized as an internal or e
On Sun, Aug 4, 2013 at 11:38 AM, Paul LeoNerd wrote:
> On Sun, 4 Aug 2013 11:29:41 -0400
> Chris Marshall wrote:
>
>> > The approach I take with Alien modules is to bundle the upstream
>> > tarball in the dist, and build/install it directly into perl's
>> > archlib directory:
>> >
>> > https://
On Sun, 4 Aug 2013 11:29:41 -0400
Chris Marshall wrote:
> > The approach I take with Alien modules is to bundle the upstream
> > tarball in the dist, and build/install it directly into perl's
> > archlib directory:
> >
> > https://metacpan.org/release/Alien-libtermkey
> > https://metacpan.org
Hi Paul, thanks for the reply
On Sun, Aug 4, 2013 at 10:10 AM, Paul LeoNerd wrote:
> On Sun, 7 Jul 2013 17:08:46 -0400
> Chris Marshall wrote:
>
>> The only alternative is to do the actual install
>> process to see if it "just works" or to drill down
>> into the implementation to determine h
On Sun, 7 Jul 2013 17:08:46 -0400
Chris Marshall wrote:
> The only alternative is to do the actual install
> process to see if it "just works" or to drill down
> into the implementation to determine how the
> module does its work and thence to deduce if
> it supports windows (64bit) for example.
On Sun, 7 Jul 2013 17:08:46 -0400
Chris Marshall wrote:
> The only alternative is to do the actual install
> process to see if it "just works" or to drill down
> into the implementation to determine how the
> module does its work and thence to deduce if
> it supports windows (64bit) for example.
All-
I've been looking at some refactoring for the
planned PDL-3.000 release this Summer based
on replacing hand-coded library detection in the
Makefile.PL processing stages by 'use Alien::XXX;'
instead. That sounds good so far.
Then I took a look at various existing Alien::XXX
modules for ideas
19 matches
Mail list logo
