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/ _______________________________________________ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make