> Date: Thu, 18 Apr 2013 19:09:06 +0200 > From: Frank Heckenbach <f.heckenb...@fh-soft.de> > > > . calculation of combined_output in start_job_command will need to be > > reimplemented for Windows, since the reliance on st_dev and st_ino > > makes assumptions that are false on Windows. > > What we need is basically "is_same_file (fd1, fd2)" (which we > probably could refactor into a separate function). Eli, can you try: > > test file1 -ef file2 > > where test is either a standalone utility or a built-in of bash or > any other shell. If any of these works, you can see how they do it. > Otherwise, a bit of googling turned up this page which has code (in > Python, but it seems like a thin layer around the system calls, so > it can probably easily be ported to C): > > http://timgolden.me.uk/python/win32_how_do_i/see_if_two_files_are_the_same_file.html
I know about this method, but I'm not sure it does what we want here. The number used by this method is not guaranteed to be unique on some versions of Windows. More importantly, it only works for disk files, I don't know whether it reports a meaningful value for the console device or the null device. So this will be a bit more tricky than that URL pretends. > > > > . STREAM_OK uses fcntl and F_GETFD which both don't exist on Windows. > > > > > > This is to test if somehow make's stdout or stderr has been closed (not > > > just redirected to /dev/null, but closed). > > > > Right, got that; but Windows needs a different test for that, as > > there's no fcntl. > > Basically we need just any call that succees for a valid file and > fails otherwise. fstat() might be a good candidate. fstat is too heavy on Windows; there are better methods. > If that isn't available, maybe even lseek() (as used in > FD_NOT_EMPTY) will do if we keep the "|| errno != EBADF" test. lseek fails for the console as well, so it's not a good candidate. But this problem is not difficult, I just mentioned that the code as committed won't compile. > Eli, can you do some tests to see if you find something that works > reliably? Don't worry about that. My worst problem is lack of time, not lack of ideas ;-) _______________________________________________ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
