[Kfwdev] comments on current build script

[Ken Raeburn]

I tried doing a build in AFS this weekend.  Actually, I was trying  
Friday, but ran into a number of mostly minor issues.  Saturday I got  
it going.  From my ramblings in jabber and other observations:


[07/04/21 17:28:11] A    krb5\README
[07/04/21 17:28:11] Exported revision 19519.
[07/04/21 17:34:40]
[07/04/21 17:34:41] \project\kfw\sources\pismere\athena\*.* copied to  
\project\kfw\sources\public\ziptemp\src\athena\

It would be useful if a message is printed before doing anything that  
may take some time.  Like copying big trees into "ziptemp", which  
took six minutes in my setup.  Well, maybe other stuff was happening  
then too, but I didn't see anything reported.


Is there a reason to require that cygwin be installed in the non- 
default location \tools\cygwin other than the hard-coded path for the  
cygwin "find" program?  (1) Using the default location for cygwin  
would be nicer, and (2) you could search PATH for "bash" and assume  
UNIX "find" will be in the same directory.


"bkw.pl ... /s ..\sources" didn't work.

Pathname parameters should be allowed to be relative.  It's not that  
hard to figure out where you're running from and convert relative  
paths to absolute ones.  (Well, maybe on Windows it's a little  
trickier, if C:foo is supposed to mean "foo" relative to whereever  
you'd be when you switch back to C: drive, which you're not in at the  
moment.  But requiring either relative paths with no drive prefix or  
absolute paths would be reasonable, I would think.)


"bkw.pl ... /s \blah\blah\blah\sources" didn't work in Z:.

The /out parameter should probably default to $src\public, not a  
separately hard-coded directory in C: under the default source location.


[07/04/21 17:34:54] Info -- Looking for filenames containing CVS
[07/04/21 17:36:45] Info -- Looking for filenames containing .cvsignore
[07/04/21 17:38:21] Info -- Looking for filenames containing Changelog

The multiple invocations of find to hunt for CVS and .cvsignore and  
ChangeLog took over five minutes.  This could be improved: "find . ( - 
name CVS -o -iname .cvsignore -o -iname ChangeLog ) ..." would find  
them in one pass.  And if the find option "-exec rm -rf {} \;"  
doesn't work in Windows, you could still run one "rm -rf" command  
with all the items to be deleted, instead of one "rm -rf" command per  
item.  And since I specified an export with a CVS tag name, you can  
skip looking for CVS anyways, I think.


[07/04/21 17:38:21] Info -- Looking for filenames containing Changelog
[07/04/21 17:49:47] Using build_local_opts.pm
[07/04/21 17:49:47] <<mit-k73bd7p53jg>>
[07/04/21 17:49:47] build.pl invoking NMAKE with the following options:

Allowing a couple of minutes for the ChangeLog search, I'm not at all  
sure where the other 9+ minutes went here.


All told, it was over 20 minutes from the end of the checkout process  
to the first compilation command, and the whole process took me two  
and a half hours.  The build I did into local "disk" (a VMware  
virtual disk, stored in a file on the host) took about 38 minutes  
total, including doing the initial checkouts (which I think were full  
checkouts, not exports, so probably involved more file system work,  
actually).  Jeff's AFS build took 3 hours, he reported, but he's in  
NYC and using a file server here at MIT.  My file server access was  
via the VPN on campus to a file server running on a SunBlade 1500 in  
my office that wasn't doing much else at the time.

It looks like a fair bit of time is spent waiting for files to be  
read or written; the VMware process doesn't get above about 80% usage  
of the host cpu unless the compiler is working on a relatively big  
file.  It's too bad Windows nmake doesn't support parallel jobs --  
let one compiler invocation crunch on one file while another one (or  
more) blocks on AFS....

Ken