|
Posted by Fred Stone on November 11, 2006, 7:42 am
Please log in for more thread options
>
>> Does there exist a Curses module for ActiveState Perl on WinXP that
>> actually supports PDCurses?
>>
>> I am a fairly experienced Windoze and GNU/Cygwin user but new to the
>> Perl environment(s). I have PDCurses working in multiple environments
>> under Visual C++ as well as under GNU/Cygwin.
>>
>> Curses-1.15 from CPAN refuses to recognize either of them. I see the
>> install note about how it is supposed to "sort of" work with
>> PDCurses, but I cannot make heads or tails of the installation
>> process.
>>
>
> Curses and PDCurses are things that I know nothing about.
>
> I'm (initially) surprised to find that there's no perl interface to
> (specifically) the PDCurses library. At least, if such an interface
> does exist, then, like you, I'm unable to locate it.
>
> Seemed to me that there's a good opportunity for someone to write such
> an interface - eg Win32::PDCurses.
>
> Anyway, with nothing better to do, I downloaded the MinGW PDCurses-2.8
> pre-compiled build (since I normally use the MinGW compiler).
>
> I thought I might be able to demonstrate to you the ease with which
> many of those PDCurses functions could be wrapped into perl functions
> using Inline::C. Those functions that cannot be wrapped *easily* could
> still be wrapped - they just take a little more thought and work. And
> all of those functions (both easy, and difficult, to wrap) could also
> be incorporated into a perl extension (module) with no dependency on
> Inline::C - if such was deemed desirable.
>
> So I wrote the following demo:
>
> -------------------------
> use warnings;
> use Inline C => Config =>
> BUILD_NOISY => 1, # verbose build
> LIBS => '-LF:/pdcurses_mingw -lpdcurses',
> INC => '-IF:/pdcurses_mingw';
>
> use Inline C => <<'EOC';
>
> #include <curses.h>
>
> int wrap_baudrate() {
> return baudrate();
> }
>
> int wrap_beep() {
> return beep();
> }
>
> EOC
>
> $ret1 = wrap_baudrate();
> $ret2 = wrap_beep();
> $size = get_sizeof_chtype();
>
> print $ret1, " ", $ret2, "\n";
> -------------------------
>
> But the compilation stage fails with the following errors:
>
> ------------------------
> F:/pdcurses_mingw/curses.h:1225:17: macro "instr" requires 2
> arguments, but only 1 given
> F:/pdcurses_mingw/curses.h:1541:1: warning: "instr" redefined
> In file included from D:/perl58_M/5.8.8/lib/CORE/perl.h:3982,
> from pdcurses_pl_5fd5.xs:2:
> D:/perl58_M/5.8.8/lib/CORE/embed.h:2375:1: warning: this is the
> location of the previous definition
> dmake: Error code 129, while making 'pdcurses_pl_5fd5.o'
> ------------------------
>
> Already there's a problem.
>
> From F:/pdcurses_mingw/curses.h we have:
> 1541: # define instr(str) winnstr(stdscr, str,
> stdscr->_maxx)
>
> And from D:/perl58_M/5.8.8/lib/CORE/embed.h we have:
> 2375: #define instr(a,b) Perl_instr(aTHX_ a,b)
>
> I wouldn't like to try and build this interface without including
> embed.h ... and I certainly wouldn't like to try and build it without
> curses.h :-)
>
> Frankly, I don't know how to deal with this collision. It may be
> simple ... or it may require that either PDCurses or Perl rename
> 'instr' to something that doesn't clash.
>
> And there may be other problems in store once that one has been
> overcome.
>
> If you can think of some possible way of getting around that problem
> without too much difficulty, then please let me know. I'd be
> interested in that - and would be quite prepared to try it out and see
> where it leads.
>
> Both my Cygwin and Visual C++-built perls also contain an 'embed.h'
> that contains the same definition, so I would think that the same
> problem applies equally to them.
>
In my C++ programs I wrap curses.h into objects so that the old C
structures become private to those objects.
And I think that's approximately what the Curses-1.15 installation
Makefile.pl is doing, though the automated process is not at all
transparent to a perl n00b like me. He's doing some weird hack to
generate compiler calls to detect each of the routines in curses.h and
then generates C macros to interface them, and then *that* gets compiled
to make the Curses.pm module.
At least that's the theory.
--
Fred Stone
--
Posted via a free Usenet account from http://www.teranews.com
| 
XML Sitemap