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 for any potential authors and to ensure that the Alien modules actually work for the end users in as portable way as possible. 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 than the perl level stuff but it seems to do the right thing here) - Have the build process give information on why things didn't work: e.g., no GNU make, libtool, tty/ptty, ... This is much more useful than "OS doesn't work" of any flavor. - If a failure occurs, provide information on how to "do it yourself" even if only a short paragraph and a link. --Chris On Thu, Aug 8, 2013 at 6:03 AM, Paul LeoNerd <leon...@leonerd.org.uk> wrote: > On Thu, 8 Aug 2013 00:51:37 +0200 > Leon Timmermans <faw...@gmail.com> 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 built Perl. So > how far down the toolchain do we allow to be missing? > > -- > Paul "LeoNerd" Evans > > leon...@leonerd.org.uk > ICQ# 4135350 | Registered Linux# 179460 > http://www.leonerd.org.uk/
