Hi,
Dodger wrote:
2009/8/4 Steffen Mueller <[email protected]>:
Hi,
Dodger wrote:
Okay, so I just made wxMac 2.8.10 successfully and installed it. Then
I went to instal the stable WxPerl, but the Makefile.PL didn't like
being on a Mac (complaints about --ldflags not being a valid option,
etc, and thus failure). So then I grabbed the latest bleeding edge
version from subversion, and went to make that. THEN I went into the
CPAN shell to install ExtUtils::XSpp (the readme might should mention
that this is a requirement, BTW) and tried again and it made, tested,
and installed just fine.
Why should it? It doesn't mention any of the other dependencies either. It's
in Makefile.PL with all other Perl module dependencies and running
Makefile.PL will tell you what's missing (unless it bombs out earlier, of
course).
Well, yeah but it's just that it would be good to see a list of
dependencies rather than wading through it and then trying to figure
out what it's looking for. Rather than saying it's missing a module, I
got:
"Cannot open 'xspp -t typemap.xsp -t ../../typemap.xsp
XS/RichTextCtrl.xsp |': No such file or directory in RichText.xs, line
65"
That's certainly bad. Did you run Makefile.PL and read its output? Did
it not warn about ExtUtils::XSpp missing? If it didn't, that's a bug. If
it did... you should have paid more attention :)
-- oh, didn't hit send. Actualy, that's good. I wasn't sure what I
should be mucking with in that. I only got these options:
Usage: perl Makefile.PL [options]
--enable/disable-foo where foo is one of: dnd filesys grid help
html mdi print xrc stc docview calendar datetime
--help you are reading it
--mksymlinks create a symlink tree
--extra-libs=libs specify extra linking flags
--extra-cflags=flags specify extra compilation flags
--[no-]wx-debug [Non-] debugging wxWidgets
--[no-]wx-unicode [Non-] Unicode wxWidgets
--[no-]wx-mslu [Non-] MSLU wxWidgets (Windows only)
--wx-version=2.6[.1]
--wx-toolkit=msw|gtk|gtk2|motif|mac|wce|...
I specifically thought of --wx-version=2.8.10.
So I did this, I took the first copy of Wx out of @INC's paths, to see
what would happen. It went like this:
Circe-2:wxPerl root# wxPerl -e 'for (@INC) { if (-d "$_/Wx") { print
"$_/Wx\n" }}'
/Library/Perl/5.8.8/darwin-thread-multi-2level/Wx
/System/Library/Perl/Extras/5.8.8/darwin-thread-multi-2level/Wx
/System/Library/Perl/Extras/5.8.8/Wx
Circe-2:wxPerl root# mv
/Library/Perl/5.8.8/darwin-thread-multi-2level/Wx* oldWxPerl/
Circe-2:wxPerl root# lss oldWxPerl/
total 24
0 drwxr-xr-x 4 wheel 136 Aug 5 05:11 ./
0 drwxr-xr-x 57 wheel 1938 Aug 5 05:10 ../
0 drwxr-xr-x 35 admin 1190 Aug 4 21:30 Wx/
24 -r--r--r-- 1 admin 9195 Aug 4 21:21 Wx.pm
Circe-2:wxPerl root# wxPerl -MWx -e 'print "$Wx::VERSION\n"'
Wx object version 0.91_02 does not match bootstrap parameter 0.74 at
/System/Library/Perl/5.8.8/darwin-thread-multi-2level/DynaLoader.pm
line 253.
Compilation failed in require.
BEGIN failed--compilation aborted.
Seems to probably be a case of library conflicts between where a
source install puts things and where Apple had put things, and Apple's
older version taking precedence, but I have very little clue right now
how to sort the whole mess out because it's seeming like there's a lot
of the mess to clean. Like a litterbox in a crazy cat lady's house.
I agree. This kind of stuff can drive people up walls. Been there.
Sorry, I can hardly help you with that.
(Though I am starting to wonder... am I the only crazy person trying
to write Mac Perl GUI apps? heh...)
Good question. In principle Padre runs on MacOS, but I think few or none
of the Padre developers are on a Mac, so there's rather little testing.
We're still looking for testers by the way :)
Best regards,
Steffen