Re: Alien::XXX needs something more
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::AssertOS::Unix checks for: The OS supports multiple concurrent users, devices are represented as pseudo-files in /dev, there is a single root to the filesystem, users are protected from interference from other users, and the API is POSIXy. It should be reasonably easy to port a simple text-mode C program between Unixes. -- David Cantrell | http://www.cantrell.org.uk/david Deck of Cards: $1.29. 101 Solitaire Variations book: $6.59. Cheap replacement for the one thing Windows is good at: priceless -- Shane Lazarus
Re: Alien::XXX needs something more
and for windows is meant Strawberry, Activestate, Cygwin, or other?
Re: Alien::XXX needs something more
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/
Re: Alien::XXX needs something more
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/
Re: Alien::XXX needs something more
On Thu, 8 Aug 2013 07:00:07 -0400 Chris Marshall devel.chm...@gmail.com 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 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. This /is/ what NA with the OS unsupported - MESSAGE does. Again; observe that with the two Alien modules I mentioned, they give NA with a message about being unable to find GNU libtool. It's not possible to easily turn this into a FAIL, because FAIL would have to mean that it did at least configure successfully, and then failed at the testing stage. At this point there isn't an easy way to notate why. - If a failure occurs, provide information on how to do it yourself even if only a short paragraph and a link. unable to find GNU libtool - surely suggests to the user that they should install GNU libtool then try again? I could add that paragraph of text if you think it would be useful. -- Paul LeoNerd Evans leon...@leonerd.org.uk ICQ# 4135350 | Registered Linux# 179460 http://www.leonerd.org.uk/
Re: Alien::XXX needs something more
On Thu, Aug 8, 2013 at 7:43 AM, Paul LeoNerd leon...@leonerd.org.uk wrote: On Thu, 8 Aug 2013 07:00:07 -0400 Chris Marshall devel.chm...@gmail.com 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 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. This /is/ what NA with the OS unsupported - MESSAGE does. I know, that is why I added the why things failed to the proposal. Again; observe that with the two Alien modules I mentioned, they give NA with a message about being unable to find GNU libtool. Yes, I know. This is with regards to the overall Alien module concept of operation and not a response to your modules which already give this type of output. It's not possible to easily turn this into a FAIL, because FAIL would have to mean that it did at least configure successfully, and then failed at the testing stage. At this point there isn't an easy way to notate why. Yes, this would be a change from how other perl modules work with CPAN Testers but it would be (I believe) much more useful for Alien modules since it would simplify getting information about when they work by looking at test output. As for implementing, as long as the perl Makefile.PL or perl Build.PL phase passes, it should be possible to have a stub 'make' or 'Build' operation that could be tested to generate the FAIL report. - If a failure occurs, provide information on how to do it yourself even if only a short paragraph and a link. unable to find GNU libtool - surely suggests to the user that they should install GNU libtool then try again? I could add that paragraph of text if you think it would be useful. I'm not sure which paragraph you propose adding but it would be at the choice of the Alien author. It is a chance to make the Alien::XXX more useful by helping out to the extent possible: - Link to library source and docs. Indirect consumers of Alien modules (through a modules's CPAN pre-requisites) may not know anything about XXX and just search the web is not helpful without some basic additional information. If the Alien author already has that, providing it would short circuit effort by an Alien use-er. - If you know how a user could get the XXX by hand, an explanation would help, since once installed, the Alien::XXX should then PASS. Cheers, Chris
Re: Alien::XXX needs something more
* Chris Marshall devel.chm...@gmail.com [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::FooBar?)
--
*AUTOLOAD=*_;sub _{s/..([^:]*)$/()[print$1,(,$\/, )[defined
wantarray]]/e;$_}
Just-another-Perl-hack;
#Aristotle Pagaltzis // http://plasmasturm.org/
Re: Alien::XXX needs something more
On Thu, Aug 8, 2013 at 9:16 PM, Aristotle Pagaltzis pagalt...@gmx.de 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
Re: Alien::XXX needs something more
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 pagalt...@gmx.de wrote:
* Chris Marshall devel.chm...@gmail.com [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::FooBar?)
--
*AUTOLOAD=*_;sub _{s/..([^:]*)$/()[print$1,(,$\/, )[defined
wantarray]]/e;$_}
Just-another-Perl-hack;
#Aristotle Pagaltzis // http://plasmasturm.org/
Re: Alien::XXX needs something more
On Thu, 8 Aug 2013 21:21:39 +0200 Leon Timmermans faw...@gmail.com wrote: On Thu, Aug 8, 2013 at 9:16 PM, Aristotle Pagaltzis pagalt...@gmx.de 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… I think we're still missing some essential question here. To take a really concrete example - does Alien::libtermkey support Linux? * It works on -my- Linux box. * It won't work on any Linux box that lacks GNU libtool, or GNU make, even though those can just be installed. * It won't work on any Linux box that lacks both unibilium and ncurses's development headers. Chris: Given the above, would you say that Alien::libtermkey supports Linux or not? If no = then surely no Alien:: module can ever be said to support -any- OS, since its dependencies could just not be present. If yes = then surely in my case at least, Alien::libtermkey can be said to support Windows too. This really is the core of my confusion here. -- Paul LeoNerd Evans leon...@leonerd.org.uk ICQ# 4135350 | Registered Linux# 179460 http://www.leonerd.org.uk/ signature.asc Description: PGP signature
Re: Alien::XXX needs something more
On Sun, Aug 4, 2013 at 5:38 PM, Paul LeoNerd leon...@leonerd.org.uk 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 external command, operable program or batch file. 'libtool' is not recognized as an internal or external command, operable program or batch file. 'glibtool' is not recognized as an internal or external command, operable program or batch file. OS unsupported - unable to find GNU libtool Similar things in unibilium. The specifics in this case are that libtermkey itself won't do anything useful on Windows, for lack of actual TTY devices, but there's no reason unibilium won't work. Its build system simply requires GNU libtool, and then it would build. Most Windows systems lack GNU libtool, so it can't be built there. If so, that is exactly the critical information needed so windows users don't go down a dead end trying to use those modules or perl modules requiring them. I haven't come up with a good way to do that for the general case. If one knows a priori any such restrictions, at least the docs should indicate that and the Makefile.PL or Build.PL could return NA in testing. But that is exactly what the OS unsupported string is for. Take a look again - running it produces that exact output: OS unsupported - unable to find GNU libtool It's far more useful to report this string, than simply telling people in advance that it won't work on Windows - because it /will/ work on any Windows box that has GNU libtool available; and also the same failure tells people on otherwise-supported platforms that simply lack a GNU libtool currently that they need to install it. Sounds like an Alien::libtool may be useful ;-) Leon
Re: Alien::XXX needs something more
On Sun, 7 Jul 2013 17:08:46 -0400 Chris Marshall devel.chm...@gmail.com 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. https://metacpan.org/release/Alien-libtermkey https://metacpan.org/release/Alien-unibilium -- Paul LeoNerd Evans leon...@leonerd.org.uk ICQ# 4135350 | Registered Linux# 179460 http://www.leonerd.org.uk/ signature.asc Description: PGP signature
Re: Alien::XXX needs something more
On Sun, 7 Jul 2013 17:08:46 -0400 Chris Marshall devel.chm...@gmail.com 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. Er, I missed the text on the first mail ;) 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/release/Alien-unibilium -- Paul LeoNerd Evans leon...@leonerd.org.uk ICQ# 4135350 | Registered Linux# 179460 http://www.leonerd.org.uk/ signature.asc Description: PGP signature
Re: Alien::XXX needs something more
Hi Paul, thanks for the reply On Sun, Aug 4, 2013 at 10:10 AM, Paul LeoNerd leon...@leonerd.org.uk wrote: On Sun, 7 Jul 2013 17:08:46 -0400 Chris Marshall devel.chm...@gmail.com 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. Er, I missed the text on the first mail ;) 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/release/Alien-unibilium For windows platforms which have no supported package manager, the only option is to either bundle the needed code or a web site to get the source or binaries. I notice that the Alien::libtermkey and Alien::unibilium appear to be unix-ish only. There were no PASSes reported for either mswin32 or cygwin platforms. It appears that since the two libraries appear to be unix-only, maybe there is no way to support windows platforms (I'm not sure why cygwin didn't work). If so, that is exactly the critical information needed so windows users don't go down a dead end trying to use those modules or perl modules requiring them. I haven't come up with a good way to do that for the general case. If one knows a priori any such restrictions, at least the docs should indicate that and the Makefile.PL or Build.PL could return NA in testing. Maybe it would be useful to carve out OS specific packages under the Alien:: moniker. What about Alien::Unix::libtermkey ? Cheers, Chris -- Paul LeoNerd Evans leon...@leonerd.org.uk ICQ# 4135350 | Registered Linux# 179460 http://www.leonerd.org.uk/
Re: Alien::XXX needs something more
On Sun, Aug 4, 2013 at 11:38 AM, Paul LeoNerd leon...@leonerd.org.uk wrote: On Sun, 4 Aug 2013 11:29:41 -0400 Chris Marshall devel.chm...@gmail.com 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/release/Alien-unibilium For windows platforms which have no supported package manager, the only option is to either bundle the needed code or a web site to get the source or binaries. I notice that the Alien::libtermkey and Alien::unibilium appear to be unix-ish only. There were no PASSes reported for either mswin32 or cygwin platforms. It appears that since the two libraries appear to be unix-only, maybe there is no way to support windows platforms (I'm not sure why cygwin didn't work). 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 external command, operable program or batch file. 'libtool' is not recognized as an internal or external command, operable program or batch file. 'glibtool' is not recognized as an internal or external command, operable program or batch file. OS unsupported - unable to find GNU libtool Similar things in unibilium. The specifics in this case are that libtermkey itself won't do anything useful on Windows, for lack of actual TTY devices, but there's no reason unibilium won't work. Its build system simply requires GNU libtool, and then it would build. Most Windows systems lack GNU libtool, so it can't be built there. If so, that is exactly the critical information needed so windows users don't go down a dead end trying to use those modules or perl modules requiring them. I haven't come up with a good way to do that for the general case. If one knows a priori any such restrictions, at least the docs should indicate that and the Makefile.PL or Build.PL could return NA in testing. But that is exactly what the OS unsupported string is for. Take a look again - running it produces that exact output: OS unsupported - unable to find GNU libtool It's far more useful to report this string, than simply telling people in advance that it won't work on Windows - because it /will/ work on any Windows box that has GNU libtool available; and also the same failure tells people on otherwise-supported platforms that simply lack a GNU libtool currently that they need to install it. Useful to whom? I think you have an optimistic view of the windows platform environment. Basically, windows can be counted on to have pretty much nothing which is why getting Alien::XXX support for windows is so difficult and why it would be a huge benefit if it did work. Maybe for the case of Alien modules, and the manifesto, the module should report a FAIL if it was not possible to make the library available. That would at least propagate through the CPAN dependency chains usefully. Also, regarding anything term* tty/ptty building and running on windows---I haven't seen any example of that working except for cygwin (which is arguably unix and not win32). Maybe it would be useful to carve out OS specific packages under the Alien:: moniker. What about Alien::Unix::libtermkey ? In this case I disagree - unibilium at least should work anywhere, being as it is purely abstract C99 code, and libtermkey will work anywhere with TTY devices. I found no information that unibilium works on windows. It is more useful to have Alien::XXX modules do the right thing when the functionality is not available to the user of that module. If the feature cannot be provided then the user should be informed of that fact in the build process and in the documentation. The author of an Alien module is the best one to provide this type of information: dependencies, requirements, limitations, etc. In this case, I understand that lack of familiarity with the windows/perl ecosystem makes it difficult to understand especially since things are so nice in the linux-centric world. I wish I could spend more time there! :-) BTW, if you know how to get terminfo/cap and tty/ptty code working on windows, I would like to know how. I've been wanting GNU readline for quite a while now... --Chris -- Paul LeoNerd Evans leon...@leonerd.org.uk ICQ# 4135350 | Registered Linux# 179460 http://www.leonerd.org.uk/
Alien::XXX needs something more
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 to start with or existing modules that could be used already. So far it is with great difficulty that I can determine whether or not a given module supports the necessary set of perl platforms: Windows, Mac OS X, and Unixen/Linuxen systems. 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. To that end, I would like to suggest an addition to the Alien module manifesto: AN ALIEN MODULE SHOULD MAKE IT VERY CLEAR WHAT PLATFORMS ARE ACTUALLY SUPPORTED. The README file and the documentation should indicate this clearly. Ideally, requirements for operation should be indicated as well. Tests should output information that would allow the Alien::XXX module author to determine what the cause of the failure was. Ironically, many of the Alien::XXX modules solve the easy case of pulling down a package via a package manager but rarely can handle platforms like windows with no standard package manager or expectation of same. I suggest a better strategy for Alien::XXX module implementations would be to first solve the problem of detecting and using existing libraries and/or software. This is much easier to do with support for most perl platforms so the Alien::XXX would *start as cross-platform* rather then the often disappointing surprise they can be now on the unsupported platforms (most often windows). Then, the Alien::XXX implementation would grow from there by adding the ability to install the library or software as well. Starting with diagnostic output on where to obtain the software might be a reasonable intermediate step as well. Thoughts or comments? --Chris
