> On Wen, Oct 1, 2014 at 4:14 AM, <[email protected]> wrote: > > On Tue, Sep 30, 2014 at 7:48 AM, <[email protected]> wrote: > > ==> Why does tup save the correct mtime for the generated Dma.o file, but > > not for DMA.out and DMA.mdf?
> I'm not sure... this is very odd. Can you try a few things to see if we get > any clues? Sure! Before I forget a short comment on the toolchain: similar to GCC it uses a control program (cctc.exe), which calls the real assembler/compiler/linker depending on command line options. So the behaviour of the compile-step and the link-step shouldn't be different from tup's point-of-view, I guess. > 1) Try replacing the linker with a simple rule like ': Dma.o |> touch %o |> > DMA.out DMA.mdf' - do you get the timestamps on the first run in this case? > If there's a way to reproduce it without the custom toolchain, that will help > me be able to look at it as well Here are the resulting database entries of using GnuWin32 touch instead of the linker (first run): id dir type mtime srcid name 9 8 2 -1 -1 DMA 10 9 0 1409313151 -1 Dma.c 625 9 4 1412164397 9 Dma.o 626 9 1 1562 -1 ^ CC Dma.c^ cctc.exe -co -o Dma.o Dma.c 627 9 4 1412164397 9 DMA.out 628 9 4 1412164397 9 DMA.mdf 629 9 1 57 -1 C:\data\CoreUtils\bin\touch.exe DMA.out DMA.mdf It looks like tup records the timestamps correctly. > 2) Try changing the linker rule to do: cctc.exe -cl -o DMA.out Dma.o && stat > DMA.out > - Does the stat find DMA.out and report a valid mtime? Here are the resulting database entries of using the combination of linker and GnuWin32 stat (first run): id dir type mtime srcid name 9 8 2 -1 -1 DMA 10 9 0 1409313151 -1 Dma.c 625 9 4 1412164717 9 Dma.o 626 9 1 1542 -1 ^ CC Dma.c^ cctc.exe -co -o Dma.o Dma.c 627 9 4 -1 9 DMA.out 628 9 4 -1 9 DMA.mdf 629 9 1 493 -1 cctc.exe -cl -o DMA.out Dma.o && C:\data\CoreUtils\bin\stat.exe -t DMA.out DMA.mdf And this is what stat had written to stdout: DMA.out 63408 128 81b6 0 0 e6371c30 16044073672638268 1 0 0 1412164718 1412164718 1412164718 4096 DMA.mdf 4472 16 81b6 0 0 e6371c30 7318349394608007 1 0 0 1412164718 1412164718 1412164718 4096 So stat sees the files with proper mtimes, but tup doesn't record a thing. Strange. And for completeness the results of a second run: id dir type mtime srcid name 9 8 2 -1 -1 DMA 10 9 0 1409313151 -1 Dma.c 625 9 4 1412164717 9 Dma.o 626 9 1 1542 -1 ^ CC Dma.c^ cctc.exe -co -o Dma.o Dma.c 627 9 4 1412164718 9 DMA.out 628 9 4 1412164718 9 DMA.mdf 629 9 1 631 -1 cctc.exe -cl -o DMA.out Dma.o && C:\data\CoreUtils\bin\stat.exe -t DMA.out DMA.mdf DMA.out 63408 128 81b6 0 0 e6371c30 106679016173469371 1 0 0 1412164982 1412164982 1412164718 4096 DMA.mdf 4472 16 81b6 0 0 e6371c30 14636698789085034 1 0 0 1412164982 1412164982 1412164718 4096 It looks like tup takes the mtime of the files before the command even begins... Any more ideas? 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.
