On Mon, 12 Feb 2001, Peter Prymmer wrote:
> > Good reminder. Is there a pod somewhere that documents all of the
> > options that can be fed in as command-line parameters? When creating
> > pre-built kits it would be particularly helpful to configure the Perl
> > administrator as 'system' instead of having the builder's e-mail
> > address appear for every installation that uses the pre-built kit.
>
> There are three documents: README.vms, @configure "-h", and to a lesser
> extent the INSTALL. file (more appropriate for unix on the whole); all of
> which could use some updating and general tweaking given the fact that
> very few of the symbols we use do f$type() type checks before setting them
> (prefix, usedevel and a few others being notable exceptions). But rather
> than worry over updating the docs I'd like to update configure.com to
> better correspond to INSTALL.
There are four documents since the [.porting]glossary. document also
gives information on what various OS and C RTL variables imply (as well as
the comments within config_h.SH). Unfortunately it looks like the
variables that you are interested in are not command line configureable
the way that prefix and a few others are:
$ sea configure.com cf_email,perladmin
$ THEN cf_email = ans
$ ELSE cf_email = dflt
$ dflt = "''cf_email'"
$ THEN perladmin = ans
$ ELSE perladmin = dflt
$ WC "cf_email='" + cf_email + "'"
$ WC "perladmin='" + perladmin + "'"
$ IF cf_email.NES.perladmin
$ WRITE CONFIG "$! perl configured by ''cf_email'"
$ WRITE CONFIG "$! This perl configured & administered by ''perladmin'"
where the dflt values are obtained from things like f$getjpi(), but we do
not check to see if someone said:
@configure "[EMAIL PROTECTED]"
But that is actually a build time issue - for installation you want to
edit the values in Config.pm in you installed PERL_ROOT. Folks can still
do that if they like. The intricacies of setting ones Config.pm properly
is one of the big arguments in favor of building perl yourself from
source.
Peter Prymmer
