At 7:23 AM -0500 11/4/02, Sherm Pendley wrote:
Here's (belatedly) what I think.
On the other hand, CB apps would be significantly larger as a result. I haven't compiled a 5.8.0 libperl.a, but libperl.dylib for 5.8.0 weighs in at about 1.1MB - and that's before including any modules. Also, the download for developers would be *drastically* larger, as it would include an entire Perl distribution - 10MB+.
So, what do you think?
No matter what you do you're going to have some problems. If you don't package the camelbones framework in the executable, then people will have to have CB on their machines, and thus no all-in-one executables.
If you ship the framework in the built executable, then you're dependent on the system perl, and thus also dependent on the user (and apple) to have not adjusted the system perl from what you're expecting.
And, if you ship perl and CB with the executable it can get somewhat large.
This is complicated by the potential dependence on extensions that the application might need. If those are shipped with the executable they make it dependent on the system perl version, and if they're not they depend on the user having installed those modules.
There are, as far as I can tell, two different target audiences here. The first wants to ship a fully contained app complete with perl, the second is fine with shipping an app that depends on the currently installed frameworks. (The latter being the best way if the app doesn't have any XS module dependencies)
Seems that the best thing to do is be able to build or package multiple ways. Not fun, certainly, as there's a lot of extra work there, but I think it's the only way to reconcile the two.
--
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
