Kwindla Hultman Kramer wrote:
>
> Hi,
>
> A couple of comments about the 0.40TRIAL4 installation...
>
> I needed to remove all of my old _Inline/config files, because the
> "denter" didn't like them. Brian probably already mentioned this in an
> earlier message about upgrading, but I missed it. I had config files
> in several places, as an artifact of doing different kinds of installs
> as different users <laugh>.
Kwindla,
Thanks for this feedback. I obviously need to do a usability test for
upgrading from 0.3x to 0.40. Here's some general feedback:
* Inline 0.40 is not backwards compatible with 0.3x and any of it's
config/cache files.
* Inline 0.50 will (probably) not be compatible with 0.4x releases, and
so on until Inline reaches 'Release' status. (It's still BETA, and will
continue that way until Neil and I (and all of you) run out of crazy
ideas to throw in the soup. The release version will (probably) be
called Inline 1.00. (If I ever refer to 1.00, that's what I mean)
* I probably need to be more emphatic about the roll of _Inline/ cache
directories. Since they are created automatically, they are completely
disposable. I delete them all the time. And it is fine to have a
different one for each project. In fact as long as you don't have
~/.Inline/ defined, Inline will create a new ./_Inline directory. You
can move that to ./.Inline and it will continue to work if you want to
give it more longevity and hide it from view. There is a long
complicated list of rules about how [_.]Inline/ directories are
used/created. But it was designed to give you the most
flexibility/ease-of-use. Never be afraid to nuke 'em. They'll just pop
right back next time. :)
* SITE_INSTALL is gone. I was going to leave it in and change the
semantics, but thought it better to remove it, so people wouldn't try to
use it the old way. There is now _INSTALL_ (but you're not supposed to
know that :). It works magically through the use of Inline::MakeMaker. I
explained this earlier but it's worth going thruogh again because it's
the biggest change for 0.40. Here's how to 'permanently' install an
Inline extension (Inline based module) with 0.40:
1) Create a module with Inline.
2) Test it using the normal/local _Inline/ cache.
3) Create a Makefile.PL (like the one produced by h2xs)
4) Change 'use ExtUtils::MakeMaker' to 'use Inline::MakeMaker'
5) Change your 'use Inline C => DATA' to 'use Inline C => DATA => NAME
=> Foo => VERSION => 1.23'
6) Make sure NAME matches your package name ('Foo'), or begins with
'Foo::'.
7) Make sure VERSION matches $Foo::VERSION. This must be a string (not a
number) matching /^\d\.\d\d$/
8) Do the perl/make/test/install dance (thanks binkley :)
* With Inline 0.41 (or thereabouts) you can skip steps 3 & 4, and just
say 'perl -MInline=INSTALL ./Foo.pm'. This will work for non-Inline
modules too. It will become the defacto standard (since there is no easy
standard) way of installing a Perl module. It will allow Makefile.PL
parameters 'perl -MInline=INSTALL ./Foo.pm - PREFIX=/home/ingy/perl' and
things like that. It will also make use of a MANIFEST if you provide
one.
* In the case below, it thinks SITE_INSTALL is the programming language!
I'll work on the heuristics and on the error messages.
Thanks again, Brian
>
> My SITE_INSTALL stopped working. I'm getting the M08 error message
> about not having any code in my DATA section, here's the info output:
>
> <-----------------------Information Section----------------------------------->
>
> Information about the processing of your Inline C code:
>
> Your module is already compiled. It is located at:
> /tmp/lib/auto/XML/Comma/Parsing/SimpleC_5a72/SimpleC_5a72.so
>
> The following Inline C function(s) have been successfully bound to Perl:
> void DESTROY(SV * self)
> SV * _c_new(char * class, char * string, char * from_file, char * doc_class)
> AV * _el_stack(SV * obj)
> void done_return()
> void eat_whitespace(SV * self)
> char * from_file(SV * obj)
> void next_token(SV * self)
> int pos(SV * obj)
> char * string(SV * obj)
> char * top_level_class(SV * obj)
>
> <-----------------------End of Information Section---------------------------->
> No source code in DATA section for Inline 'SITE_INSTALL' section.
>
> at test.pl line 0
> END failed--cleanup aborted.
> not ok 1
> make: *** [test_dynamic] Error 255
>
> The error is correct; I don't have any code in a DATA section (I don't
> even have a data section.) I use the Inline'ed classes from inside an
> eval string inside a BEGIN block, it's (arguably) cleaner to do that
> with a heredoc than with a DATA section. Here's a simplified view of
> what I'm doing (which worked with 0.33):
>
> package Main_Stuff;
> BEGIN {
> my $tmp_dir = "/tmp";
> my $parser = "foo.pm";
> eval "use $parser";
> die "can't use parser class: $@" if ( $@ );
> }
>
> package foo;
> BEGIN {
> eval "use Inline Config => DIRECTORY => '$Main_Stuff::tmp_dir'";
> die "configuring: $@\n" if ( $@ );
> my $code = <<'END';
> --code here--
> END
> eval 'use Inline C => $code';
> die "compiling inline: $@\n" if ( $@ );
> }
>
> I moved things around to put the code in a DATA secion -- getting rid
> of foo's BEGIN block and the code heredoc. That works fine when just
> using the module, but the SITE_INSTALL still doesn't work; I get the
> error message about needing Inline->init:
>
> ----
> It appears that you have used the 'DATA' form of Inline.pm but one or more
> code sections were not processed. This is because the internal INIT block
> could not be invoked automatically. You need to do it manually by placing the
> following command after you Inline command(s).
>
> Inline->init;
>
> We apologize for the inconvenience.
>
> - the Management
> ----
>
> When I add the Inline->init call I'm back to a "No source code in DATA
> section" error message:
>
> ----
> can't use parser class: compiling inline parser code: No source code in DATA section
>for Inline 'SITE_INSTALL' section.
>
> at (eval 4) line 1
>
> BEGIN failed--compilation aborted at (eval 2) line 2.
>
> BEGIN failed--compilation aborted at blib/lib/XML/Comma.pm line 69.
> BEGIN failed--compilation aborted at test.pl line 14.
> not ok 1
> It appears that you have used the 'DATA' form of Inline.pm but one or more
> code sections were not processed. This is because the internal INIT block
> could not be invoked automatically. You need to do it manually by placing the
> following command after you Inline command(s).
>
> Inline->init;
>
> We apologize for the inconvenience.
>
> - the Management
>
> make: *** [test_dynamic] Error 255
> ----
>
> Again, everything runs great -- it's just the SITE_INSTALL that I
> can't figure out how to make work, in the context of use'ing inside
> BEGIN/eval.
>
> Thanks again to Brian for all the great work,
> Kwin
