NWCLARK TPF grant report #48

[Hours]		[Activity]
2012/07/30	Monday
 0.50		Dumper.xs on non-gcc
 0.25		HP-UX make and symlink targets
 3.25		reading/responding to list mail
=====
 4.00

2012/07/31	Tuesday
 0.25		HP-UX make and symlink targets
 2.00		RT #114356
 5.50		bisect.pl (for RT #114356)
 0.75		reading/responding to list mail
=====
 8.50

2012/08/01	Wednesday
 0.25		COW
 0.75		HP-UX make and symlink targets
 0.25		RT #114312
 1.25		RT #114356
 0.25		RT #114372
 0.50		bisect.pl (target 'none')
 2.50		reading/responding to list mail
 0.25		smoke-me/require
=====
 6.00

2012/08/02	Thursday
 0.25		RT #114102
 4.00		reading/responding to list mail
=====
 4.25

2012/08/03	Friday
 2.25		reading/responding to list mail
=====
 2.25
[2:13]		-2

 0.25		CPAN #78768
=====
 0.25

Which I calculate is 25.25 hours

The HP-UX fun continues this week. What would one expect this Makefile to do?

$ cat Makefile 
bar: foo
	cp $? $@

baz: foo
	ln -s $? $@


Here's AIX, not known for being the most flexible platform:

$ touch foo
$ make bar
        cp foo bar
$ make baz
        ln -s foo baz
$ make bar

and repeat:

Target "bar" is up to date.
$ make baz
Target "baz" is up to date.

Every other make I tried behaves the same. *Except* HP-UX:

$ touch foo
$ make bar
        cp foo bar
$ make baz
        ln -s foo baz
$ make bar
`bar' is up to date.
$ make baz
        ln -s foo baz
ln: baz exists
*** Error exit code 1

Stop.


Special. So the symlink is never up to date (and one has to work round this
by always deleting it). I kiss you!

(And don't let's talk about HP-UX make's "support" for parallel makes.)


Also of note this week, and far less hateful, I added a --timeout feature to
permit the git bisect wrapper to time out (and kill) the user's test case if
it takes longer than the specified time to run. With this I was able to
bisect a problem that I'd noticed had appeared recently with debugging
builds seeming to hang if PERL_DESTRUCT_LEVEL=2 is set in the environment
(RT #114356) I hoped that having identified the commit, it would be a
one-line fix. Of course, whether it was, and if so *which* one line wasn't
at all obvious to me. Fortunately it was to Dave (or he made it seem so) as
he was able to fix it with commit d97935e01b36de89.

Nicholas Clark

• NWCLARK TPF grant report #48 by Nicholas Clark