Re: Multiple meanings for --with-perl in AutoFu?
Jeff Johnson wrote: The AutoFu (which has been remarkably resilient, thank you!) for RPM may soon have two or more meanings for --with-perl if I seriously pursue embedding perl (and python and ...) into rpm. I'll use --with-embedded-perl as a marker for my insanities for now, that is rather easy. Adding a new configure option (or two) would be preferred over changing the meaning of the currently existing ones... But I've always wanted to rip out MakeMaker from rpm/perl, because of the MakeMaker buggy incompatibilities and arcaneness when trying to build perl bindings as part of a larger RPM build. What's in rpm/perl is OK, and can be lived with, but isn't perfect for many reasons. So would that mean rpm/perl would be a separate install, like the rpm/ruby is now (mostly for licensing reasons but anyway) ? --anders __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
Re: [CVS] RPM: rpm/ CHANGES configure.ac devtool.conf rpm/rpmio/ .cvsignor...
Jeff Johnson wrote: Log: - ruby: add --with-ruby for embedding ruby. Shouldn't that be --with-rubyembed then, like the others ? (Or maybe --with-embedded-ruby like you mentioned earlier.) --with-ruby should be for building the ruby bindings, yes ? (like the ones available from http://ruby-rpm.rubyforge.org/) --anders __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
Re: [CVS] RPM: rpm/ CHANGES configure.ac devtool.conf rpm/rpmio/ .cvsignor...
On Apr 8, 2009, at 1:58 PM, Anders F Björklund wrote: Jeff Johnson wrote: Log: - ruby: add --with-ruby for embedding ruby. Shouldn't that be --with-rubyembed then, like the others ? (Or maybe --with-embedded-ruby like you mentioned earlier.) --with-ruby should be for building the ruby bindings, yes ? (like the ones available from http://ruby-rpm.rubyforge.org/) No clue atm. I do expect that, say, --with-perl checking for ExtUtils::Embed as a side effect is more consistent with how Ralf has done the existing rpm AutoFu (and he has already pointed that out) than the easy-to-remove and orthogonal --with-perlembed that I created^Whacked-up instead. I still haven't a clue whether (or how) embedding script interpreters is a good idea or not. All I've been doing so far is looking at feasibility, and the answer so far is Hmmm, feasible, yes, seeing is believing. 73 de Jeff__ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
Re: [CVS] RPM: rpm/ CHANGES configure.ac devtool.conf rpm/rpmio/ .cvsignor...
Jeff Johnson wrote: Shouldn't that be --with-rubyembed then, like the others ? (Or maybe --with-embedded-ruby like you mentioned earlier.) I still haven't a clue whether (or how) embedding script interpreters is a good idea or not. All I've been doing so far is looking at feasibility, and the answer so far is Hmmm, feasible, yes, seeing is believing. Just looked odd next to the other two, but by all means don't let that get in the way of the experimentation... I'm thinking that Tcl is about as heavy as I want myself, but that's another story. (i.e. Perl/Python/Ruby too much) --anders __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
Re: [CVS] RPM: rpm/ CHANGES configure.ac devtool.conf rpm/rpmio/ .cvsignor...
Jeff Johnson wrote: I'm thinking that Tcl is about as heavy as I want myself, but that's another story. (i.e. Perl/Python/Ruby too much) If you grep WITH_TCL in rpm code (and look at rpmio/rpmtcl.[ch]), the manifestation of tcl-rpm is quite small and reasonable. [...] But I wholeheartedly agree, embedding interpreters is *VERY* conceptually heavy aven if the implementation(s) are quite straight forward. Right, I didn't meant the number of lines of interfacing code but more like the size of the interpreter requirements or the cost of invoking the interpreter (or even to keep it running) and there is the what would you need all that power for ? I can see how Lua/Tcl scriptlets could have a lower overhead than forking a shell, and how a full scripting language is better than having to jump through hoops in spec or make shell scripts when *building* the packages. But at runtime ? I'm not sure. --anders __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
Re: [CVS] RPM: rpm/ CHANGES configure.ac devtool.conf rpm/rpmio/ .cvsignor...
On Apr 8, 2009, at 3:33 PM, Anders F Björklund wrote: I can see how Lua/Tcl scriptlets could have a lower overhead than forking a shell, and how a full scripting language is better than having to jump through hoops in spec or make shell scripts when *building* the packages. But at runtime ? I'm not sure. FYI: one of the data points I discovered while figgering embedding (for perl? ruby? I fergit) was a comparison between # of instantiations/sec for multiply embedded interpreters in C++ or something:. The numbers I remember (and I can/will dig out the ref if needed, but I always benchmark using rpm --stats because its easier than trying to decipher how I'm being lied to w some benchmark ... ymmv) was lua:~150 instatntiations/sec ruby~100 instantiations/sec python: ~40 intstantiations/sec I would expect that perl, which tends to have more modules to load than python, is gonna be no faster than python. And tcl was the original embedded scripting language (after forth) and so I'd expect something similar to lua for tcl interpreter instantiations. Note: instantiations/sec is meaningless if you have a persistent global interpreter. Duh. So the original choice of lua for embedding in rpm is/was quite sound if performance (and memory footprint) is/was the primary criteria. It is/was. ;-) Again, YMMV, everyone's does. But now you can __CHOOSE__ in RPM ;-) 73 de Jeff__ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
