On Fri, Oct 3, 2014 at 04:29 AM, Mike Shal <[email protected]> wrote: > The generated files are initially added to the database when the Tupfile is > parsed, > and have an mtime of -1 there. However, after the command actually executes, > tup is > supposed to stat each file and see what the new mtime is and save that to the > db. > For some reason, that isn't happening in Bernhard's case. To me it's looking > like > a bug in tup - I'd guess however it is creating the files is slightly > different > from how other programs like gcc do it, but it's hard to guess why.
> Bernhard, are you comfortable running your toolchain through Procmon to see > what > calls are used to create DMA.out and such? Or, I could try to add some debug > statements to tup and send you a new exe to try. After more experimentation I got the following results: Like GCC the Tasking control program cctc.exe just calls different sub-programs depending on command-line parameters and other information. For compilation, cctc.exe will call the compiler (ctc.exe) and assembler (astc.exe). For linking it will call the linker (ltc.exe). When I replace the cctc.exe-based commands in my Tupfile with the sub-program commands as cctc.exe would call, I get the same issue. In my opinion this means cctc.exe is not guilty. The next thing I did was to monitor the sub-programs with procmon. The compiler and the assembler both will open their source file and write to their output file as specified on the command-line. Interestingly, the linker processes its files in a different way: the output files will be created at first with a random temporary name, and when the linker is done with processing, it will rename these files to their final name as specified on the command-line. Later I tried another thing. As I do not have access to the Tasking compiler at home, I made up some simple batch files which emulate the behaviour of the Tasking sub-programs: <ctc.cmd> copy main.c nul echo foo > %1 </ctc.cmd> <ltc.cmd> copy main.o nul echo bar > temp123a move temp123a %1 </ltc.cmd> <Tupfile> : main.c |> ctc.cmd %o |> main.o : main.o |> ltc.cmd %o |> main.elf </Tupfile> This setup is even worse, as tup won't detect any write access to main.elf and error out with "tup error: Expected to write to file 'main.elf' from cmd 32 but didn't". Replacing the "move temp123a %1" with the almost equivalent "copy temp123a %1 && del temp123a" makes tup behave correctly again. To me it looks like tup doesn't catch renames correctly. I haven't dug any deeper so I can't tell if it is tup's or the injected dll's fault. I could share the procmon log-file of my batch file experiment in case it helps. Kind regards, Bernhard. -- -- tup-users mailing list email: [email protected] unsubscribe: [email protected] options: http://groups.google.com/group/tup-users?hl=en --- You received this message because you are subscribed to the Google Groups "tup-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
