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/
