Your theory breaks down about the time you have to compile a module. Many Windows machines do not have MSVC, or Cygwin, installed. In fact, short of developers, I would imagine that could be constrained to 'most'.
Far less likely is a Unix machine without a compiler. While it's unusual, in my experience, it's not unheard of.
Another flaw in that whole argument is deployment. I don't about ActiveStates latest versions (I'm running 5.005_03), but there's no pretty installer method that allows the IT 'droid to walk up to a machine, run an installer, and *poof*, the application with all the required pieces are installed. While Redhat has RPMs, and BSD has their thing (I don't know about it), Windows has Install Shield. However, Install Shield does not lend itself well to installing Perl applications, especially ones that require module compiliation.
In theory, I think you can compile the modules once on the developers machine, and distribute the .O files. I've never tried this, as I've never deployed a non-server based Perl application. But, nonetheless, deploying an application is a major pain in the rear-end.
What Perl needs is a friendly multi-platform installer (read: Linux, Windows, Mac). Some kind of facility for a integrated target compiler, or a way to optionally precompile the binaries for each platform, and install according to the platform being run on. What would would be really slick is a tiny Perl app that runs as an executable, that reads meta-instructions from the distribution file, and basically boot straps up to a full blown uninstalled version of Perl in the distribution file. This would allow a complete non-dependancy on any installed software on the target machine. I'm imagining something like PkUnZip or an RPM type package that has been generated for all platforms.
You could optionally reduce the distribution file size by making it a requirement that Perl and/or certain modules be already installed. But, with todays 'net bandwidth, and density of CDROMs, who cares if the distribution file is 600K or 600Mb, if you can do a bare-OS up install?
It's my contention that a mechanism like that would *really* make Perl take off, particularly on Windows and Mac OS machines.
(And I don't want to hear any "Windows is better than Linux/Linux is better than Windows" crap. Perl needs to transcend OS-centric views in life, and be truly cross-platform, not be an invoker of religeous wars.
--Chris
e-mail jcwren | [reply] |
In our environment, we have two classes of machines (well, typically 3 or more, but I'm generalizing): development and production. On a development machine, I would expect a compiler and all of the tools I would need to build an application, including all of the necessary modules. On a production machine, we, for example, have no compilers. The machine is locked down and designed only to accept content originating from the development machine. We can get in to fix things, but new binaries or code must come pre-written and ready for use.
Since Perl modules must be built on target platforms, this makes things difficult for us. We have to either resort to a manual installation or just hope that the module doesn't use any non-Perl code and that it can simply be copied to a target directory.
What I would like to see Perl have is not only a way to package modules (or at least dependency information so that the modules can be fetched a la CPAN at application install time), but a way to roll out a set of modules to a production server from a development one.
Note: Code samples are for conceptual use only and generally are not meant to be cut/pasted into a production application. Always 'use strict', have a thorough understanding of the code you use, and check the return values of functions and handle errors according to your needs. - Fastolfe
| [reply]
[d/l] |
ActiveState distribute binary versions of a selection of modules,
most of the common ones - but not all of them - which they keep reasonably up to date.
It's a relatively simple matter to install them (there's a perl script who's name I've forgotten, which downloads the packages and installs them).
If you've actually purchased ActiveState you get a nice GUI which does the same thing as the script.
This would certainly be easier to use than RPM's (who wants to find the RPM's themself?!).
And is also easier than using CPAN directly since the user/admin doesn't have to download the package, configure it then compile it.
In reply to the latter part of you message, perhaps take a page from Debian's book and have servers which automatically compile the packages on the server.
Then when you install the package it also works out all the dependencies and installs those packages as well (and their dependencies etc).
I do see a major problem with this approach though, there are modules which you want
to configure for each machine (location of libraries which it depends upon) which vary.
This could be fixed by adding shared librarys to LD_LIBRARY_PATH or /etc/ld.so.conf.
If we could make some nice automated compilation/installation system that would be really
neat. I think it's possible too...
| [reply] |