[Israel.pm] Re: Installer for a Perl and Web Meta Language based program.

Shlomi Fish shlomif at iglu.org.il
Mon Apr 12 02:12:09 PDT 2004

On Monday 12 April 2004 06:41, Tzafrir Cohen wrote:
> On Mon, Apr 12, 2004 at 05:55:22AM +0300, Shlomi Fish wrote:
> > Hi good people!
> >
> > I have developed Quad-Pres, which is a presentation tool based on Perl
> > and Web Meta Language (http://thewml.org/) first for my own use and now
> > distribute as open source software.
> WML is mostly some perl modules. 

Wrong! It is some Perl module, some standalone C programs, some extensions 
written in its own language, and some man pages.

> You should package them. There are a 
> number of useful scripts for that (e.g: cpanflute). So you should
> package them separately.

I think I can assume a recent version of Web Meta Language is installed on the 
system prior to running my installation script. Otherwise my script will fail 
and request the user to install WML.

> If QuadPres has some perl scripts/modules that use those modules then an
> automatic dependency will be created.
> (You may need to add a build-time dependency, though)
> I installed WML on a certain Mandrake 9.2 system recently. I'll see if I
> can find the rpm I made.

Why did you make an RPM? There are already pre-made RPMs available in cooker 
or contrib.


> > Now, up to now, after I revamped the program to be centralized in the
> > system, I used GNU Autoconf and Automake to manage the program's
> > "compilation" and installation. The problem is that now I have several
> > tests and the process I'm using to invoke them from Autoconf is "icky":
> > it's slow, cumbersome and unfit for a Perl program.
> >
> > I'm looking for a nice alternative installer, preferablly written in Perl
> > (which I can already assume is installed there), that I can use to
> > perform the preparation, testing and installation. Rolling something on
> > my own should not be too hard, but I'd rather use an available solution
> > if possible.
> >
> > I'll describe here what the various components of the program do and how
> > they are installed: (you can skip to the requirements below)
> >
> > 1. First there's the quadp Perl executable that invokes the appropriate
> > Perl module that is installed, not in the standard perl path but in it's
> > own dedicated path. This executable is used as a wrapper for all
> > user-land commands.
> There is always cons and such programs. However this (IIRC) requires a
> non-standard program, unlike configure that only requires the basic
> core-utils.

WDYM exactly? quadp is installed by the installer in /usr/bin/ and is a simple 
Perl wrapper:

#!/usr/bin/perl -w -I/usr/share/quad-pres/perl5

use strict;

use Shlomif::Quad::Pres::CmdLine;

my $cmd_line =
        'cmd_line' => [@ARGV],



=head1 NAME

quadp - the Quad-Pres Interface

[... Other Perl POD snipped ]

> > 2. Under /usr/share/quad-pres/perl5/ several Perl modules are present
> > that perform most of the logic of the command line program, as well as
> > some of that that is provided as an extension to the Web Meta Language
> > code. (see below). This code should be somehow @INC'ed into all
> > invocations of the program.
> >
> >
> >
> > 3. Under /usr/share/quad-pres/wml/ lies a hierarchy of web meta language
> > include files. Now Web Meta Language is a very powerful processor for
> > HTML files and it has ePerl as one of its passes. This ePerl in turn
> > calls logic from the modules in #2. quadp and its supporting scripts (see
> > below) invoke the wml interpreter with a this directory in the include
> > path.
> Why do you assume that the user does not have WML installed? Make it a
> separate package and install it to its standard localtion.

I do assume WML is installed. 

> > 4. Under /usr/share/quad-pres/scripts there are several scripts written
> > in Perl that are invoked by the quadp+modules Perl code to perform
> > several tasks. These are largely remnants of the history of Quad-Pres and
> > I'm now seriously considering integrating their logic into the main quadp
> > code.
> >
> > 5. There's a man page at /usr/share/man/man1/quadp.1.(bz2|gz)
> %{_mandir}/man1/quadp.1*

What will this help me? I'm not going to write the installer using rpm. I need 
it to be runnable on any UNIX system.

> Different distros will use different ocmpression methods (RH: gz, MDK:
> bz2). The compression is done automatically in the scripts that run
> after the %install phase.

Fine, I'll install the man page uncompressed.

> > 6. There are some documents under /usr/share/doc.
> %doc

I suppose I can live it to the RPM to install it.

> > ------------------
> >
> > Basically, what the installer needs to do is:
> >
> > 1. Temporarly install all the components in a local path for easy
> > testing.
> >
> > 2. Determine the prefix from the command line (an Autoconf like --prefix)
> > and be able to install everything there. (with a modified prefix for the
> > local installation)
> Makefile.PL should support this. Why reinvent the wheel?

My problem with Makefile.PL and ExtUtils::MakeMaker is that it tends to 
install all the Perl modules in the Perl executable @INC path. This is 
something I wish to avoid. I'd like the Perl modules to be installed in the 
application ${prefix}/share/quad-pres path.

> > 3. Determine the location of the Perl interpreter and set the
> > #!-locations in the quadp executable and scripts accordingly.
> >
> > 4. Pre-process some Perl files for them to contain the path under which
> > everything was installed.
> >
> > 5. Process files from a directory tree that corresponds to what will
> > later be installed.


Shlomi Fish      shlomif at iglu.org.il
Homepage:        http://shlomif.il.eu.org/

Quidquid latine dictum sit, altum viditur.
        [Whatever is said in Latin sounds profound.]

More information about the Perl mailing list