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