Dan Sugalski wrote:
> I'd go this all one step further and say you ought to be able to do this:
>
> $ @configure "-des"
Presumably such a step would be undesirable in a configure.com generated
build_perl.com since all config issues have already been taken care of
in the initial run of configure.com (that generated build_perl.com).
Is this not so?
> $ mmk
> $ mmk test
> $ if $status .eq. %X00000001
> $ then
> $ MMK install
> $ endif
>
> or something similar, presumably with a real test against $status.
Should be OK. BTW C<$ if $status .eq. 1> ought to work OK too - except
for the fact that I don't think a failure propagates out of MMK or MMS at this
time:
[.pragma]warnings.......FAILED on test 216
Failed 3/221 tests, 94.57% okay.
u=17.18 s=0 cu=0 cs=0 files=212 tests=9419
11-MAY-2000 13:43:39.52 User: PVHP Process ID: 00021CFE
Node: TRUMP Process name: "PVHP_1"
Accounting information:
Buffered I/O count: 56536 Peak working set size: 6496
Direct I/O count: 2661 Peak virtual size: 180336
Page faults: 8426 Mounted volumes: 0
Images activated: 46
Elapsed CPU time: 0 00:00:17.20
Connect time: 0 00:07:08.38
%DELETE-I-FILDEL, DKB100:[PERL-5_6_0.T]ECHO.EXE;1 deleted (18 blocks)
$ sho sym $status
$STATUS == "%X10000001"
> Should we consider a DWIM target (MMK DWIM! Yeah!) that builds, tests, and
> then installs if the tests succeed?
So that the interactive build becomes this two step process?:
$ @configure
$ mmk dwim
Sounds reasonable, except for the fact that I think that if you do:
$ @configure
$ mmk install
the dependencies are such that targets "all" and "test" ought to fall into
place - is this not so? I have no time to test that right now....
Peter Prymmer.
