Peter Prymmer writes:
> On Thu, 19 Apr 2001 [EMAIL PROTECTED] wrote:
>> Peter Prymmer <[EMAIL PROTECTED]> writes:
>> > The time has apparently come to get rid of the attempt to pass
>> > a list of extensions to build to the make_ext.com script.
>> My suggestion is to have the take the list of extensions (stored in
>> multiple DCL symbols) to generate multi-line config.sh entries. Then
>> have make_ext.com read config.sh for the list of extensions to build.
> Thanks for the suggestion. Currenty config.sh is Bourne shell syntax not
> DCL so we cannot issue:
>
> @config.sh
>
> and have the extensions symbol automatically assigned in our local DCL
> scope.
Right, one has to use a bit of DCL and scan through config.sh
> I reached for the extensions.lis file for a couple of reasons:
> 1) it was an analog of a linker options .opt file 2) it seemed that it
> would be really easy to parse 3) it seemed that it would be really easy to
> modify by the end user. As it stands I cannot now use EDT to edit my
> config.sh since it exceeds EDT's 255 character per line limit - hence I
> have to use TPU or VIM.
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...
And splitting the extensions='...' line should only help your editor
problems!
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.
> 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.
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?
--
Drexel University \V --Chuck Lane
======]---------->--------*------------<-------[===========
(215) 895-1545 _/ \ Particle Physics
FAX: (215) 895-5934 /\ /~~~~~~~~~~~ [EMAIL PROTECTED]
