Re: unGNUifying mkcheck

[Phil Edwards <pedwards at jaj dot com>]

(If you reply to the list, please don't cc another copy to me.  Thanks!)

> The problem is that I really want to do that "etime" thingy where 
> the execution time of the binaries is clocked--that will give me a better 
> idea of where changes impact performance, in a rough and imprecise (but 
> better than the status quo) way. Of course, I haven't done this yet, so 
> this is all a bit of hand-waving.

Profiling Is Good.  Thus sayeth the Knuth.


> And to do this, I was thinking of using yet more "bash" isms, like the 
> time shell command. I suppose tho, that this too could be abstracted out.

I saw the one shell function stub (swanky_timer or some such) to do this
and wondered whether I was taking a step backwards.  I keep forgetting that
traditional sh is the only shell without a 'time' builtin.


> I suppose this only takes things farther away from working reliably on 
> Solaris, which is really your point.

While Solaris is my current major platform, I'd really love to get it
working better on IRIX, which is even more idiosyncratic, and NT, which is,
well, NT.  :-)


> Perhaps mkcheck should just be a 
> straight "sh" script and  call sub-scripts or executables to do the weird 
> stuff? (YUCK)

That would be ugly, agreed; it's why my patch strips the 'now' binary,
to reduce the page-in by every little bit it can.  It's arguable that the
fork'n'exec'n'wait overhead is effectively a /constant time/ overhead that
would vanish when the start and finish times are subtracted.  (It's arguable
that the previous argument is complete and utter crap, though.)


> I dunno. . . . I have run into problems with ksh being 
> installed, so maybe the best bet is just "sh."

Striking a balance between portability and standardization is fun.
Until recently I was not aware that the X/Open 4 Standard specifies exactly
what a Bourne shell is supposed to do, and that in fact such an XPG4 sh
/is/ ksh -- that's why I suggested ksh rather than, say, perl, since more
recent commercial Unixes will have ksh, somewhere.  (Forgot about all the
free ones, *duh*.)  As it happens, under Solaris, if you put /usr/xpg4/bin
before /usr/bin in your path in order to get XPG4 Standardized behavior,
you find that /usr/xpg4/bin/sh and /usr/bin/ksh are linked together.

It's also worth noting that anybody likely to install libstdc++-v3 is probably
going to have other GNUisms already there.  Perhaps bash is not such a
bad idea (it's what I use under Solaris for a login shell myself), but I
was hoping to reduce the number of "required tools" as much as possible.
Building and installing is currently very painless even for a novice user;
mkcheck makes collecting testsuites equally painless, but only if /bin/bash
is present.

Perhaps another behavior flag to mcheck, in addition to the present "test the
local build" vs "test the installed files" flag?  One that says, "just see if
stuff compiles and runs at all using this sh script," versus one that says,
"also do timing tests using this slightly bigger bash script."


Phil
(pedwards@jaj.com/philip.edwards@{sn.wpafb,afrl}.af.mil