Greetings,

The latest round of updates to configure.com have recently been
posted here at best:

   http://www.best.com/~pvhp/vms/cfgperl_6529/

where you'll want to pick up the configure.com6.gz file along
with several patches (if you haven't picked them up already)
to the specified perl kit.

The big news in this update is a significant user visible change in
command line arg handling and the possiblity of a few persistent 
symbols influencing the build.  At this time several variables
having influence over the installation location are now "-D" settable
from the command line (or via global symbols assignments).  I have 
checked it out with a test configure invoked with:

   @configure "-Dprefix=dkb100:[perlfoo.]" "-des"

and the build and test went ok (as good as we've gotten a patched 6529 kit
at any rate), note the crumbs left behind in config.sh:

File DKB100:[000000]CONFIG.SH;1

config_args='-Dprefix=dkb100:[perlfoo.] -des'

Note in particular that the config_args variable has everything in one string
without double quotation marks.  The current implementaiontion of command
line parsing needs to strip " from strings.  Hence you *cannot* set something
like one of the format strings with the likes of:

    "-Duvuformat=""lu"""

(also note that the value of uvuformat is not checked for an external
setting anyway...)

As mentioned the variables that are settable via either global
symbol assignments or via "-Dvar=value" include these (shown
with the values they took in my build):

archlib='perl_root:[lib.VMS_AXP.5_6_0]'
archlibexp='perl_root:[lib.VMS_AXP.5_6_0]'
bin='/perl_root/000000'
binexp='perl_root:[000000]'
builddir='perl_root:[000000]'
installarchlib='perl_root:[lib.VMS_AXP.5_6_0]'
installbin='perl_root:[000000]'
installman1dir='perl_root:[man.man1]'
installman3dir='perl_root:[man.man3]'
installprivlib='perl_root:[lib]'
installscript='perl_root:[utils]'
installsitearch='perl_root:[lib.site_perl.VMS_AXP]'
installsitelib='perl_root:[lib.site_perl]'
oldarchlib='perl_root:[lib.VMS_AXP]'
oldarchlibexp='perl_root:[lib.VMS_AXP]'
privlib='perl_root:[lib]'
privlibexp='perl_root:[lib]'
sitearch='perl_root:[lib.site_perl.VMS_AXP]'
sitearchexp='perl_root:[lib.site_perl.VMS_AXP]'
sitelib='perl_root:[lib.site_perl]'
sitelib_stem='perl_root:[lib.site_perl]'
sitelibexp='perl_root:[lib.site_perl]'

Variables not dealt with at all on VMS include:

vendorarchexp=''
vendorlib_stem=''
vendorlibexp=''

Note that for some reason the prefix that gets 
written to config.sh is:

prefix='perl_root'

rather than the $trnlnm of prefix.  We also have a couple of new 
variables:

perl_root='dkb100:[perlfoo.]'
vms_prefix='perl_root'

and I would very much like to see if we can set prefix to remain
the physical dev name + dir (e.g. dkb100:[perlfoo.]) rather than
being 'perl_root' >> Todo.

Note that unlike the mess on unix (where they only set gccversion if
gcc is being used) we can now refer folks to run 
`perl -"V:ccverson"` because we now have (e.g.):

ccversion='60090001'

I am still somewhat uncomfortable with introducing the RCS style 
variables:

Author='$Author'
Date='$Date'
Header='$Header'
Id='$Id'
Locker='$Locker'
Log='$Log'
RCSfile='$RCSfile'
Revision='$Revision'
Source='$Source'
State='$State'

Before I forget to mention it: the command line "-Uvar" and "-Uvar="
type parameters now work too.

BUGS:

archname gets written twice to config.sh.

Should gidformat contain " characters?  It appears to be:

gidformat='lu'

The prefix mess is a bug.

The RCS variable should be considered a bug until I can get
a hold of a perforce guru.

MORE TODO:

The procedure does not yet check for nor attempt to write a config.com.

The procedure does not deal with a prior config.sh at all.

Try to have only a config.sh file rather than a config.sh and a config.local
files for the interactive editing option.

The procedure does not check the user specified prefix: 
    device mounted?
    directory exists?
    write directory if it does not exist?
    test and warn about writability?

Should we even consider MAXBLOCKS tests of the destination filesystem?

The procedure does not check the PGLFLQUO of the initiating process
against a minimum value (100000?).

MORE TESTING: 

Does "-M" still work?  Does a "-des" config.sh have all the 
same installation paths that an interactive configure has as well as
an interactive configure where the user opts not to skip the 
remaining "where install" type questions but does wind up taking all
the defaults.  Does `mms install` work?  Do extra modules install?

Thanks for any feedback.

Peter Prymmer






Reply via email to