> From: Paul Smith <p...@mad-scientist.net> > Cc: Frank Heckenbach <f.heckenb...@fh-soft.de>, bug-make@gnu.org > Date: Tue, 23 Apr 2013 16:54:33 -0400 > > Without knowing what kind of resource Windows can take locks on, we > can't really know how to help with that.
The only resources that don't need their names passed to sub-Make are the standard streams. I will see if locking works on console handles; if not, I will have to introduce a command-line argument for passing the name or the handle of a mutex to a sub-Make. > we can do whatever the equivalent of inheriting an open file > descriptor is on Windows... Doesn't help unless it's a file descriptor of one of the 3 standard streams. Any other descriptor needs to be passed on the command line, for the same reasons we have --job-server-fds option. > > If we really want to make this reasonably portable (and without that, > > I cannot see how Paul's dream about less ifdef's is going to > > materialize), this code needs IMO to be refactored to make the > > algorithm know less about the implementation details. > > Personally I've never had any luck trying to create portable code from > scratch, at least not unless I'm very familiar with all the platforms > which is certainly not the case here. > > Once we see the second implementation it will be a lot more obvious what > needs to be done to make this more portable. That's one way. Another one is to discuss the design more thoroughly before the patches are accepted. I tried to turn the discussion that way when the issue was first brought up, but my comments were largely ignored (if I compare what was suggested then with what was eventually committed), and most of the discussions were about the details of the Unix implementation anyway. _______________________________________________ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
