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

Reply via email to