Steffen Mueller wrote:
Hi list,
for quite some time now, I have been dissatisfied by that PAR is (at
least) two things at once which is frequently not understood by those
investigating PAR for one or the other things:
a) A Perl packager
==> To standalone executables
==> To .par archives
b) A module to use .par archives as libraries (hence the JAR <=> PAR
analogy)
Part a) requires C compilation during the build process. All the build
problems that have cost some of use lots of time and hair to resolve are
related to this. In particular, only the standalone-executable part
requires the C.
Part b) is entirely independent of part a). You can rip out PAR.pm and
PAR/Heavy.pm and just use that without caring about the packaging stuff
at all.
Naturally, using PAR for loading .par files is a completely separate use
case than using it for packaging applications or libraries. Requiring
users of case b) to have a C building environment is ridiculous!
Enough introduction. The solution would be to split PAR into a
distribution for loading .par's and one for packaging. (I.e. the rest)
The pure-perl distro would contain PAR.pm, PAR/Heavy.pm and associated
tests. Possibly some or all of the .pod files (PAR/FAQ.pod,
PAR/Environment.pod, PAR/Tutorial.pod). Most of the .pod files are more
related to the packaging part, though.
A new PAR::Packer distro would contain the rest of the .pm files
(PAR/Packer.pm, App/PAR/Packer.pm, PAR/Filter/*, PAR/StrippedPARL/* and
so on), the current myldr/ subdirectory, the current script/
subdirectory with pp, par.pl et al, and, of course, the rest of the
tests. The contrib/ directory would probably also better fit into this
distribution.
I'm sure I forgot some parts of the current distribution.
From the dependency side of things, PAR::Packer would depend on PAR.
The other way around wouldn't buy us much.
Anyhow, what this would gain is is that PAR itself becomes the
light-weight .par loader it should be. It would be easy to install even
without a C build environment and have fewer dependencies. Also, it
would serve as a cleaner distinction of functionality. Beginners would
know that they actually use PAR::Packer == pp for packaging stuff and
not "PAR".
The disadvantages of this, however, would be numerous:
=> Dependency issues. People installing PAR would not get the packaging
stuff any more! This would cause a lot of head-ache.
=> Lots of documentation tweaks would become necessary.
=> Binary-packaging issues. People providing PAR binaries right now
would have to switch.
=> More distributions to maintain.
A different approach would be to provide a PAR-Lite distribution which
clones the code from PAR and PAR::Heavy. Two CPAN distribution providing
the same packages is just way broken, so I stopped thinking about this
right at that point.
Any thoughts?
Steffen
P.S: This would be such a drastic change that I won't just jump the gun
and do it without some input, so don't be too scared. In particular, I
will talk to Audrey before doing anything about this.
>Requiring users of case b) to have a C building environment ....
1) There would be exceptions of course, but in the main only developers
would use par/pp, almost all of which would have compilers.
2) The *nix variants all come with compilers. Windows developers could
obtain PAR-X.XXX-MSWin32-x86-multi-thread-YY.YY.YY.par from kind souls
who would volunteer to upload it. That is how I used to do it before I
got MinGW. Developers on other operating systems, well, um, er, hmmm, ... ?
