# from Sisyphus # on Monday 25 September 2006 03:31 am: >There was a post on perlmonks recently where someone was trying to use > PAR's pp utility to convert a script to a standalone executable.
Enough said. > a WRITE_XS_FILE_ONLY > option and have a ready-built XS file and Inline.h appear quickly in > the nominated location <snip> >And then run the Inline::C script with the config option: > >WRITE_XS_FILE_ONLY => ['.', 'Module', 'My::Module', 'My::Module'] Ok, I still don't like the idea of manually modifying the code as part of the build process. IIRC, one couldn't do the above as a -MInline=... argument because of the array ref, but we can work through that. >And quickly end up with Module.xs and INLINE.h in the cwd. <snip> >> c) What happens to the other perl code in the .pm file with "use >> Inline..." ? > >I was thinking mainly of being able to generate an XS file from code > in a script, rather than a module. <snip> > All you need to do now is add the Module.pm, Makefile.PL, <snip> > Of course, then you would need to supply a different > Polygon.pm - removing the Inline stuff, and adding a bootstrap(). And here is the real rub for me. Most of my Inliney modules started life that way and I would prefer to continue development in that mode rather than switching to XS. It sounds like your use-case is more along the lines of "generate the XS and start a module around it." Aside: I would be interested in hearing other use-cases and/or how many people are running Inline in "module" or "script" mode. Perhaps http://scratchcomputing.com/developers/live-install.html will help illustrate my development environment. I work with most of my modules symlinked from svn working copies into a $PERL5LIB path (ala "stow".) So, modifying *the* .pm file as part of the build process (and particularly, modifying it manually) is a real hassle. But, you've convinced me that it would be worth putting the XS on CPAN and making the dependency on inline be "devel_requires" only. So, my ideal implementation of the inline2xs thing: 1) allows generation from unmodified inliney code 2) integrates with a build system as "xs", "xsinstall", "xsdist", "xsdisttest" targets (or thereabouts) Mostly, this just means "let's implement it in a way that can be completely externally controlled." But, it is also worth mentioning my very strong aversion to modifying generated code. Note that (1) actually represents an improvement over the current convention of requiring a 'VERSION => ..." entry in the import arguments. By "unmodified", I mean only at-time-of-build. I'm fine with requiring some particular modifications, as long as the same code will run both "live" and as prebuilt xs. As for generating XS-only modules from scripts (i.e. dropping inline altogether at time of modularization), I think module-starter could be made to do this for you with something just like your above suggestion. The commonality between the "start module" and "transform module" is only that we need to know where to find the Inline-related files, which is well-served by something *like* `-MInline="-WRITE_XS=>.; Module; My::Module; My::Module"' (or we follow the current ~questionable practice of looking in @ARGV for arguments.) So, Module::Starter::InlineConvert maybe? Now, (2) is really just a note on what is implied by (1). Particularly, having 2 Inliney files in a given dist, more than one module in lib/, and a few other issues pop-up. How does this fit the current pm_to_blib functionality? We'll need something like pm_to_xs, xs_to_blib. Also, we're talking about modifying the .pm's along the way by removing the Inliney bits and adding bootstrap statements. I suppose just marking the code with special comments would be a good first step, so maybe: s/\n#.Inline.stuff.here.\{\{\{.*\n#.end.Inline.stuff.\}\}\}/ \n# snipped Inline stuff\n/x; Alternatively, breaking the module into swappable parts might do it, though that would incur a continual (if small) startup cost even after installation. The trade-off is us debugging code munging vs each author debugging their own code-swapping code. Yes, PPI would work, but I'm inclined to think we're better off with the commenty scheme, since my code typically does some BEGIN {stuff} before use Inline which wouldn't be required in the XS scenario. Though maybe just regen/copy everything from MANIFEST plus the xs bits and then modify the .pm files? perl Build.PL ./Build xs cd xs perl Build.PL ./Build test ./Build dist --Eric -- "Matter will be damaged in direct proportion to its value." --Murphy's Constant --------------------------------------------------- http://scratchcomputing.com ---------------------------------------------------
