File list hash not updated
Title: File list hash not updated I'm seeing an odd behavior, and can't figure out what it might be. We using VPATH, and we're using it to find source files. One of the directories in the path only has two files in it when the make begins, but gets populated with more source files by a rule along the way. Here's the thing: on many machines, future rules to compile those files find them properly, using the VPATH. On other machines, they do not compile because gmake can't find them; but if gmake is run again, the VPATH file hash is populated with the files properly, and they build fine. It seems that the correct behavior is to act like the one that does it all in one pass; the VPATH hash apparently becomes updated when those source files are created in that directory. Can anybody think of why the other machines are not doing this? We're using gmake 3.77, the same binary on both machines; the same behavior occurs if we try 3.79.1. The 'working' cases have all been on Windows 2000, and 'non-working' cases have been on Windows 2000 and Windows 98. I can provide 'gmake -d' and 'gmake -p' output from both cases, if anybody wants to look at them. Any hints or suggestions would be helpful. Thanks! -- Doug Shea Configuration Manager - WIDCOMM, Inc (858) 795-3425 http://www.widcomm.com/
RE: File list hash not updated (FAT32 problem)
Title: RE: File list hash not updated (FAT32 problem) An update to this... I believe I've found the problem: it doesn't work when run on files in a FAT32 filesystem. I've made a sample makefile, below. This makefile breaks on Win98 or Win2k, using the 3.77 and 3.79.1 gmakes, on FAT32; when the 2000's filesystem is converted to NTFS, then it works. SRC = file1.c file2.c file3.c file4.c OBJ = $(patsubst %.c,%.o,$(SRC)) VPATH = src final.exe: src/file3.c $(OBJ) echo $(OBJ) > $@ %.o: %.c echo $< > $@ src/file3.c: echo data > src\file3.c echo data > src\file4.c clean: del *.o del final.exe del src\file3.c del src\file4.c Create a subdir called 'src', with two files called 'file1.c' and 'file2.c'. You can see the makefile creates 'file3.c' and 'file4.c' in the 'src' directory, and then tries to "compile" them all and then "link" 'final.exe'. This will work on NTFS, and not on FAT32. Is this known and/or expected behavior? Is there something in the makefile that I should be doing to make it officially 'see' the new files in the 'src' dir? Thanks! -- Doug Shea Configuration Manager - WIDCOMM, Inc (858) 795-3425 http://www.widcomm.com/
RE: File list hash not updated (FAT32 problem)
Title: RE: File list hash not updated (FAT32 problem) I see. Does that mean that a well-placed "sleep" command somewhere in the makefile might make it work? Say, after creating those files, hang out for a bit to let the timestamp become sane, and then proceed? -- Doug Shea Configuration Manager - WIDCOMM, Inc (858) 795-3425 http://www.widcomm.com/ > -Original Message- > From: Paul D. Smith [mailto:[EMAIL PROTECTED]] > Sent: Wednesday, January 30, 2002 10:14 AM > To: Doug Shea > Cc: '[EMAIL PROTECTED]' > Subject: RE: File list hash not updated (FAT32 problem) > > > %% Doug Shea <[EMAIL PROTECTED]> writes: > > ds> An update to this... I believe I've found the problem: > it doesn't > ds> work when run on files in a FAT32 filesystem. > > FAT32 has a bogus feature: timestamps have only 2 second (or > was it 3?) > granularity, not 1 second. There is some code to deal with > that in the > DOS port but I think it hasn't been properly translated into > the Windows > port, for precisely this reason: in Windows we don't know whether the > filesystem is FAT or NTFS. > > -- > -- > - > Paul D. Smith <[EMAIL PROTECTED]> Find some GNU make tips at: > http://www.gnu.org > http://www.paulandlesley.org/gmake/ > "Please remain calm...I may be mad, but I am a > professional." --Mad Scientist >
RE: info
Title: RE: info Gmake has the option "-d" that will output a large amount of very detailed information about what it's doing and why. I suggest you re-direct this to a file. Also, the "-p" option will print out the definitions of all internal macros and targets. I've used both these options to good effect when debugging my makefiles. Note that I am "just another user"; Paul Smith might have more or more correct info on this. -- Doug Shea Configuration Manager - WIDCOMM, Inc (858) 795-3425 http://www.widcomm.com/ > -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] > Sent: Friday, February 01, 2002 8:20 AM > To: [EMAIL PROTECTED] > Subject: info > > > Hello, > > I'm sorry to bother you on this e-mail address, > but I am working with quiet complex makefiles > and would like to know if it exist a debugger or 'tracer' for make. > > Can you help me ? > > Regards > Bruno > > > ___ > Bug-make mailing list > [EMAIL PROTECTED] > http://mail.gnu.org/mailman/listinfo/bug-make >
