[bug #33138] .PARLLELSYNC enhancement with patch

[David Boyce]

Follow-up Comment #4, bug #33138 (project make):

This is the original author. I've become very busy at my day job in the last
year or two so I've lost track of this. Thanks for picking it up and improving
it. I haven't had time to look at your new patch yet, and not sure when I
will, but here are a few responses to your comments:

> Target vs flag

I have to agree that a flag is more "correct". It's more convenient to use
.PARALLELSYNC because getting users to use a flag can be difficult (in fact
the major insight of Feldman's original make was that a naive user should be
able to just type "make" and the right thing will happen), but a flag is more
flexible. To the best of my memory (not so good) the reasons I went with a
special target are:

1. Given the clever --eval flag Paul added in 3.82 any special target can be
used as a flag, e.g. "--eval .PARALLELSYNC:" (BTW I tried to argue that --eval
was worthy of a scarce single-letter alias (-E) on the grounds that it was a
flag-to-end-all-flags but I don't think that happened).

2. Paul has some concerns about make "becoming like GNU tar" which apparently
has too many options. Personally I'm always willing to trade a few more
minutes of RTFM for more capability, and have no problem with GNU tar, but
tastes differ.

Bottom line, I'm more or less agnostic on flag-vs-target.

> tmpfile vs mkstemp

IIRC the reason I used tmpfile() instead of mkstemp() is that mkstemp doesn't
unlink the file automatically, which leads to a number of risk factors such as
filling up /tmp and so on.

Possibly the best/most portable approach would be to refactor the existing
open_tmpfile() function, which returns a FILE *, into an open_tmpfd() which
returns a descriptor wrapped by open_tmpfile() which just converts the
descriptor into a FILE * using fdopen(). This is already what happens, it's
just a matter of splitting existing logic into two functions. Now open_tmpfd()
is logically just mkstemp-with-porting-hacks and we could enhance it with an
"unlink" option for this feature.

> make[1]: Leaving directory 'bar' 
> make[1]: Leaving directory 'bar'

The problem with doubling these is that it becomes non-deterministic. What if
there was a directory structure foo/bar/bar/baz?

Additionally, would it be possible to implement the enhancement proposed in
the email discussion? See
http://lists.gnu.org/archive/html/bug-make/2011-04/msg00041.html for context?
Or was that already done? I don't remember.

Last, Paul has been pretty clear lately that new patches should be accompanied
by associated regression tests. That might be the remaining hurdle.

    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?33138>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/