makefile thoughts

[John P. Linderman]

Andy Dougherty <doughera at lafayette.edu> said:
> Disclaimer:  I am in no way a "parallel make" expert.
> I just read the fine manuals and experiment with variants
> of make debugging flags.

I'm no expert either, but after buying myself a shiny new
quadcore PC, I've been parallelizing (or sometimes paralyzing) 
some makefiles so I can move more than 1 CPU bar on the
system monitor.  I often use the construct

  @ARGV = qw( file1 file2 file6 ) if ((@ARGV == 0) && -t);

in scripts, so I don't have to remember the files that should
be used by default, but I can pipe a small sample input in
for testing.

One nasty surprise everyone should know about is (with gnu make):

    Another problem is that two processes cannot both take
    input from the same device; so to make sure that only one
    command tries to take input from the terminal at once,
    make will invalidate the standard input streams of all but
    one running command. This means that attempting to read from
    standard input will usually be a fatal error (a `Broken pipe'
    signal) for most child processes if there are several. It is
    unpredictable which command will have a valid standard input
    stream (which will come from the terminal, or wherever you
    redirect the standard input of make). The first command run
    will always get it first, and the first command started after
    that one finishes will get it next, and so on.

This can render -t false in parallel makes, so ARGV remains empty,
and (the empty) standard in is read, not the default files.
Makes that work just fine without -j can break mysteriously
(and not always repeatably) with it.  In fact, running "nohupped"
can produce similar results (since the terminal is "disconnected"),
but at least the steps *always* run with no input, not the timing-
dependent behavior that parallel make can induce.

My solution has been to plug in the default file names in the
makefiles.  That's a bit unfortunate, because the defaults are
now exposed both in the command and in the makefile, but it
does shake the dust off a couple more cores.  -- jpl