develooper Front page | perl.perl6.language | Postings from February 2001

Re: Auto-install (was autoloaded...)

Thread Previous | Thread Next
Dan Sugalski
February 8, 2001 09:29
Re: Auto-install (was autoloaded...)
Message ID:
At 02:43 PM 2/8/2001 -0200, Branden wrote:
>Dan Sugalski wrote:
> >
> > I'm not sure this is all necessary. Wouldn't we be reasonably better off
> > we instead just shipped off bytecode compiled versions of the scripts?
> > Seems easier to ship that way than as an archive of stuff. (We can, if its
> > deemed useful, define the bytecode format in a way that allows us to
> > package up versions of modules that can be optionally loaded from the main
> > perl install instead)
> >
> > Seems simpler, and it also means you can, at the time the program is
> > initally compiled, crank up the optimization level a lot so you're handing
> > out the fastest version of your code you can.
> >
> > Dan
> >
>At a first glance, I really found that's much better. But I saw three small
>1. updating the version of modules in the big-bloated-bytecode would
>potentially have to recompile the script and all other modules.

If the modules you're distributing change you need to repackage things up 
anyway. Not much difference here, really. (And we wouldn't necessarily want 
to automagically use a newer version of an installed module--that'd be 
rather unpleasant if we have another case like we had with GD)

>2. it doesn't work for scripts/modules deployed in source code format.

Why are you assuming the source can't be packaged up in the generated bytecode?

>3. it doesn't work for modules that use C extensions.

Definitely an issue, but packaging up a program with code that needs to be 
compiled on the target machine is problematic in a lot of ways anyway.

>Actually, I think the archive approach is more general, because it wouldn't
>have this kind of problems and would allow other resources to be deployed
>together with the code, like documentation, perhaps even text files and
>images used by a Perl/Tk application.

This is an excellent reason, and one I hadn't considered. I withdraw any 
objections. Care to put together a PDD on how it should be handled? 
(Including Archive::Tar as part of the base perl distribution's not 
inappropriate, assuming we can get permission. )

>Did I miss something here? Is it just me, or you also think this
>(deploy/install) is essential for a language be used by `layman-users', and
>not only JAPHs.

Generally speaking, I assume installs require a certain minimum competence 
on someone's part. The less want assumed on the part of the end user, the 
more is required on the part of the person packaging up the install. (It's 
been my experience that it's an inverse cube relationship)

Doing this portably is an interesting exercise. Doing it non-portably is a 
waste of time, since if you're going to be platform-specific you're better 
off using the platform install tools.


--------------------------------------"it's like this"-------------------
Dan Sugalski                          even samurai                         have teddy bears and even
                                      teddy bears get drunk

Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About