[prev in list] [next in list] [prev in thread] [next in thread] 

List:       perl5-porters
Subject:    Re: [perl #70912] -V does not escape whitespace in config_args
From:       Andy Dougherty <doughera () lafayette ! edu>
Date:       2009-11-30 17:05:41
Message-ID: alpine.DEB.2.00.0911301123120.30890 () fractal ! phys ! lafayette ! edu
[Download RAW message or body]

On Mon, 30 Nov 2009, H.Merijn Brand wrote:

> On Sat, 28 Nov 2009 15:22:53 -0800, Frank Wiegand (via RT)
> <perlbug-followup@perl.org> wrote:
> 
> > I configured my perl (see below) with
> > 
> > % sh Configure -de -Dusedevel -DDEBUGGING=both -Doptimize='-g' -Dcc=ccache\ gcc \
> > -Dld=gcc "-Dprefix=/opt/perl/perl-1259411222/" -Dmad 
> > -V:config_args should give me this line after compiling perl:
> > 
> > % perl5.11.2 -V:config_args
> > config_args='-de -Dusedevel -DDEBUGGING=both -Doptimize=-g -Dcc=ccache gcc \
> > -Dld=gcc -Dprefix=/opt/perl/perl-1259411222/ -Dmad'; 
> > I can't find any documentation about config_args, but I expect it to
> > look like my original configure line, because there is a big difference
> > between C<-Dcc=ccache\ gcc> and C<-Dcc=ccache gcc>.

Yes, as others have indicated, config_args doesn't try to preserve spaces.

However, I'd certainly agree there's no way for you to know that, since 
they are not actually documented.

These config_arg* variables are not documented for a couple of reasons.

1.  What to do with the them when re-loading an old config.sh is tricky.
    The original plan was not to include them at all in the old config.sh
    file.  (As a technical implmentation detail, they were then set up
    as "temporary" variables in metaconfig, which don't have glossary
    entries and don't end up extracted into the Config.pm
    documentation.)  
    
2.  The individual config_arg1, config_arg2, etc. commands are not
    included due to a technical limitation in metaconfig (the tool used
    to generate Configure).  Metaconfig requires that all variables be
    declared, but at the time when Configure is generated, we don't know
    how many config_arg? variables are going to be needed.  Since they
    weren't going to be saved anyway (see item 1 above) it was simpler
    to just not worry about them.

The problems of reloading an old config.sh file have since been mostly
(but not completely ) cleared up, I think.  Subsequently, a section
to manually include them in the generated config.sh file (and hence in
Config.pm) was added to Configure.  (Actually two such manual sections
were added, resulting in them being included twice.)

Currently, if you re-run Configure with fewer options than the previous
time, the erroneous extra config_arg? variables are still included in
the generated config.sh file, but the config_argc counter is correct.
Thus regenerating the Configure command line can be done, as long as you
use the config_argc counter, and not all the config_arg[0-9] variables.

I expect that the config_args, config_argc, and config_arg0 variables
could now be added as real metaconfig variables, and hence automatically
documented, but I don't see an easy way to include the individual
config_arg[0-9] variables.  In the current config.sh, they are all
together at the top.  Adding some of them as real metaconfig variables
would end up slitting them up, and might also require some minor changes to
how the command-line options get stored and used in Configure.
(Simply copying all of UU/cmdline.opt to config.sh would result in
duplicating those new variables, for example.)

On balance I suspect that the best path forward might be to specially
document them in the mkglossary script used to generate Porting/Glossary.
(This is a tool included in perl's metaconfig distribution.)

I'll try to have a go at that this week.

> I'd consider this not-a-bug

Yes, I'd agree, though it is perhaps one would could document a bit
better.

-- 
    Andy Dougherty		doughera@lafayette.edu


[prev in list] [next in list] [prev in thread] [next in thread]