On Thu, 19 Apr 2001, Charles Lane wrote:
> I would *think* that if extensions are added or removed, that we'd
> want that fact reflected in $Config{extensions}. And (see below) that
> comes from config.sh. Having config info in two independent places is
> a prescription for confusion...
I think we are agreed on this point.
> And splitting the extensions='...' line should only help your editor
> problems!
As a first pass I can handle a long extensions='' since we are still about
a factor of 4 below the 1024 limit.
> A quick looks through a recent config.sh shows that the various
> extensions lines are the longest, followed by startperl (yeah, my fault)
> and some signal stuff.
>
> We could split 'em all at 80 (72?) columns and make old-time Fortran
> programmers like me happy.
I split things in myread at 80. A more sophisticated approach would parse
through the output of SHOW TERMINAL and readjust the right hand margin
accordingly. A much better approach for both myread and config.sh would
incorporate a word wrappering algorithm from a word processor to at least
get lines split up on whitespace. On the other hand if we simply split on
space via f$element(i," ",extensions) we wouldn't need a sophisticated
line splitter (what you call "whole hog" below).
> > The problem with splitting up the extensions variable in config.sh comes
> > from the regression tests that tend to do things like:
> >
> > BEGIN {
> > use Config;
> > if $Config{extensions} !~ /\bFoo\/Bar\b/
> > print "1..0 # Module Foo::Bar not built here.\n";
> > exit;
> > }
>
> Actually, that shouldn't be a problem...$Config{extensions} comes from
> Config.pm, which is generated from config.sh by the ConfigPM. Perl
> script. ConfigPM knows to handle and reconstitute split lines in config.sh.
>
> As for how make_ext.com would get it's information...just open config.sh
> with DCL and scan through it. With the long lines split up, DCL should
> handle it fine.
>
> I already do a scan like this in my default "BUILD.COM" procedure,
> since otherwise I forget whether to define __DEBUG__ or not...easier
> to just have it check config.sh and Do The Right Thing:
>
> $ mmk_opt = ""
> $ open/read CONFIG config.sh
> $ loop:
> $ read/end=eloop CONFIG line
> $ if (line .nes. "optimize='/Debug/NoOpt'") then goto loop
> $ mmk_opt = "/macro=(""__DEBUG__=1"")"
> $ eloop:
> $ close CONFIG
>
> Instead we'd just do a f$element(0,"=",line) and look for "extensions",
> and then start grabbing lines until we find the ending quote.
OK.
> If we go whole-hog with splitting lines in config.sh, then there'd
> be one line per extension:
>
> extensions='re
> File::Glob
> Filter::Util::Call
> IO
> List::Util
> MIME::Base64
> Opcode'
>
> and the DCL parsing gets rather simple. Perhaps ugly, but who looks at
> config.sh?
I do agree that grabbing info from config.sh is preferable. Nevertheless
(call me argumentative ;-) I can't help but point out that you've argued
that you want the information in config.sh, but that nobody bothers to
look at config.sh.
But actually I agree with you on the latter point too. On Unix the
Makefile has a dependency such that if someone has updated the config.sh
file then the Makefile will re-extract itself from the Makefile.SH,
thereby making last minute tweaks to config.sh valuable on Unix.
Unfortunately since we are saddled with Bourne syntax for config.sh it is
nowhere near as easy on VMS to accomodate such config.sh hacking. A pity.
Peter Prymmer
