Inline::Java on win32
Ed Peschko
I was looking for a good Inline::Java environment on win32, and was hoping to base it
off of ActiveState(s) version of perl. Hence, I'll need to be able to:
a) compile perl such that it is compatible with activestate's version
b) compile c modules
c) compile and use java modules through Inline::C.
Does anyone have any suggestions on a good environment to support this, and furthermore
does anyone actually have an environment like this with which they do development?
Thanks much,
Ed
Sisyphus
----- Original Message -----
From: "Ed Peschko" <es...@pge.com>
To: <inl...@perl.org>
Cc: <activ...@listserv.activestate.com>
Sent: Monday, March 13, 2006 10:32 AM
Subject: Inline::Java on win32
> hey all,
>
> I was looking for a good Inline::Java environment on win32, and was hoping
to base it
> off of ActiveState(s) version of perl. Hence, I'll need to be able to:
>
> a) compile perl such that it is compatible with activestate's version
That's straightforward. Irrespective of which compiler you use to build your
perl, just accept the defaults in the win32/makefile (or win32/makefile.mk)
and you'll end up with AS-compatible perl. (You can't accept *all* of the
defaults - there are some settings in there that relate to "locations" that
you might want to change - but just accept those defaults that are not in
obvious need of change. Also, not all of the config options need to be
identical. I know you'll need to build a multi-threaded perl, but I'm not
exactly sure about which other options *need* to match. )
> b) compile c modules
ActiveState use MSVC++ 6.0, so to be thoroughly compatible with them you'll
want to use that compiler. You could also use the MinGW compiler, or the
free (.NET 2003) compiler that Microsoft have made available. In any case,
make sure you read the README.win32 that ships with the perl source. The
.NET 2003 compiler uses a different C runtime library to VC++ 6.0 - and that
*can* create a difficulty if you try to mix binaries - but it's a problem
that occurs rarely (even if you do mix the binaries). The MinGW compiler
uses the same runtime C library as MSVC++ 6.0 but you might find
difficulties (related to Config.pm values - and not insurmountable, anyway)
if you try to use a MinGW-built Inline::Java on AS-built perl (or vice
versa) - but any binaries built using Inline::Java should, I expect, work on
both MinGW-built perl and AS-built perl - so long as both perls have been
built with the same config options. If you don't want to use MSVC++ 6.0 to
build your win32 perl, I would recommend using the freely available MinGW
compiler in preference to .NET 2003. (The MinGW compiler works seamlessly
with the latest and subsequent releases of AS perl.)
> c) compile and use java modules through Inline::C.
>
I don't actually use java or Inline::Java - but I don't envisage there would
be any problem in building/using it on win32, assuming both java and the C
compiler are properly configured. I'd try to compile it, but I don't think I
have the requisite java stuff. MinGW comes with a 'jar.exe' and a
'gcj.exe' - but Inline::Java seems to want more than that - namely
javac.exe and java.exe. Perhaps renaming 'gcj.exe' to 'java.exe' would
partly fix that problem.
Hopefully there's someone around who is actually using Inline::Java with AS
perl. If not, then I hope this helps.
Cheers,
Rob
Matt S Trout
I'd suggest having a look at CamelPack, which provides AS perl plus a compiler
plus nmake from a single installer (and will omit components you already have)
--
Matt S Trout Offering custom development, consultancy and support
Technical Director contracts for Catalyst, DBIx::Class and BAST. Contact
Shadowcat Systems Ltd. mst (at) shadowcatsystems.co.uk for more information
+ Help us build a better perl ORM: http://dbix-class.shadowcatsystems.co.uk/ +
Ed Peschko
> >
> > I was looking for a good Inline::Java environment on win32, and was hoping
> to base it
> > off of ActiveState(s) version of perl. Hence, I'll need to be able to:
> >
> > a) compile perl such that it is compatible with activestate's version
>
> That's straightforward. Irrespective of which compiler you use to build your
> perl, just accept the defaults in the win32/makefile (or win32/makefile.mk)
> and you'll end up with AS-compatible perl. (You can't accept *all* of the
> defaults - there are some settings in there that relate to "locations" that
> you might want to change - but just accept those defaults that are not in
> obvious need of change. Also, not all of the config options need to be
> identical. I know you'll need to build a multi-threaded perl, but I'm not
> exactly sure about which other options *need* to match. )
well, there are two main issues here
1) Has activeperl integrated all of its changes back into the mainline?
2) with mingw, would modules written in C++ be compatible with the VC++
ones?
I'm assuming that #2 won't work correctly because the two c++ compilers would have
have to be ABI compatible, and AFAIK visualc++ uses a proprietary ABI.
So - how do you go about getting VC++ version 6.0? I'll try camel-pack, but
I'm assuming that this is using mingw, so that issues with #2 would be a problem,
especially with win32-specific issues (ie: using precompiled modules from ppm)
Then again, using VC++ might cause problems with sun's java SDK.. argh.. Anyways,
I'll give it a try, and let people know how it goes (assuming that no-one has done it.
If someone *has* done it, I'd appreciate hearing from them.. )
Ed
Sisyphus
----- Original Message -----
From: "Ed Peschko"
.
>
> well, there are two main issues here
>
> 1) Has activeperl integrated all of its changes back into the
mainline?
I don't understand that question.
> 2) with mingw, would modules written in C++ be compatible with the
VC++
> ones?
>
> I'm assuming that #2 won't work correctly because the two c++ compilers
would have
> have to be ABI compatible, and AFAIK visualc++ uses a proprietary ABI.
>
> So - how do you go about getting VC++ version 6.0?
Only legal way of getting hold of it is to purchase it. There's an el-cheapo
version (called "Standard Edition", I think) but it doesn't optimise code.
Other than that its quite acceptable.
> I'll try camel-pack, but
> I'm assuming that this is using mingw, so that issues with #2 would be a
problem,
> especially with win32-specific issues (ie: using precompiled modules from
ppm)
>
I actually don't think there will be issues with 2). There are a number of
C++ modules on cpan - which build fine with either MinGW or MSVC. (Both
MinGW and VC++ have both C and C++ compilers, btw.)
I *think* there are problems if you try to get MinGW to link to a VC++-built
C++ import library (because of name mangling). Are you thinking of trying to
do that ? If I'm right about this, it's a problem only with C++ libraries,
not C libraries. And the problem doesn't really have any direct bearing on
perl that I can see.
The ppm issue is not usually ... ummm ... an issue :-)
So long as the critical configuration options (such as multi-threading)
match, then binaries built with VC++-built perl work fine with MinGW-built
perl and vice-versa.
Cheers,
Rob