Hello group,
I’m using tup on Windows 7 to build an embedded software project (using a
proprietary non-GNU tool-chain). First off, almost everything works as
expected, so a big “Thank You” is in order!
Now to my issue, tup keeps rebuilding some generated files although the inputs
haven’t been changed. It prints warnings like this:
“tup warning: generated file 'DMA.mdf' was modified outside of tup. This file
will be overwritten on the next update, unless the rule that creates it is also
removed.”
Relevant parts of tup’s files:
<Tuprules.tup>
# macro for calling the C compiler
!cc = |> cctc.exe $(CFLAGS) $(CFLAGS_%f) -co -o %o %f |> %B.o
# macro for calling the incremental linker
!li = |> cctc.exe $(LIFLAGS) -cl -o %o %f |> | %O.mdf
</Tuprules.tup>
<Tupfile>
# list of source files
SRCS += Dma.c
# compile source files
: foreach $(SRCS) |> !cc |> {OBJS}
# incrementally link object files
: {OBJS} |> !li |> DMA.out
</Tupfile>
This is what should happen on a build:
Compile: Dma.c -> Dma.o
Link: Dma.o -> DMA.out + DMA.mdf
The file I want is DMA.out, but the linker will also create DMA.mdf. It is not
possible to turn off this behavior. Both files will have a slightly different
time-stamp according to Windows, but the mtime seems to be low-res enough to be
the same.
The following things can be observed:
*) After calling tup for the first time in the project directory I get the
following related entries in .tup/db, table "nodes":
id dir type mtime srcid name
9 8 2 -1 -1 DMA
10 9 0 1409313151 -1 Dma.c
614 9 4 1411982330 9 Dma.o
615 9 1 1573 -1 ^ CC Dma.c^ cctc.exe -co -o
Dma.o Dma.c
616 9 4 -1 9 DMA.out
617 9 4 -1 9 DMA.mdf
618 9 1 452 -1 ^ LI DMA.out^ cctc.exe -cl
-o DMA.out Dma.o
When using Cygwin 'stat -c "%y %Y %n" *' to inspect the mtimes of these files I
get the following:
2014-08-29 13:52:31.765693400 +0200 1409313151 Dma.c
2014-09-29 11:18:50.212643000 +0200 1411982330 Dma.o
2014-09-29 11:18:50.638674400 +0200 1411982330 DMA.out
2014-09-29 11:18:50.643674900 +0200 1411982330 DMA.mdf
==> Why does tup save the correct mtime for the generated Dma.o file, but not
for DMA.out and DMA.mdf?
*) After calling tup a second time (this time without any changes to the source
files), I get the tup warning message. This makes sense as the mtime of the
DMA.mdf / DMA.out files is not the same as the database entries. Here are the
observed values:
Tup database:
id dir type mtime srcid name
9 8 2 -1 -1 DMA
10 9 0 1409313151 -1 Dma.c
614 9 4 1411982330 9 Dma.o
615 9 1 1573 -1 ^ CC Dma.c^ cctc.exe -co -o
Dma.o Dma.c
616 9 4 1411982330 9 DMA.out
617 9 4 1411982330 9 DMA.mdf
618 9 1 462 -1 ^ LI DMA.out^ cctc.exe -cl
-o DMA.out Dma.o
Cygwin stat:
2014-08-29 13:52:31.765693400 +0200 1409313151 Dma.c
2014-09-29 11:18:50.212643000 +0200 1411982330 Dma.o
2014-09-29 11:36:14.785185300 +0200 1411983374 DMA.out
2014-09-29 11:36:14.791185900 +0200 1411983374 DMA.mdf
==> It looks like tup saves the mtime of the DMA.mdf / DMA.out files before
they have been updated by the linker. But why does it work with the Dma.o file?
*) When calling tup a third time (again without changes to the source files), I
get the same behavior again:
Tup database:
id dir type mtime srcid name
9 8 2 -1 -1 DMA
10 9 0 1409313151 -1 Dma.c
614 9 4 1411982330 9 Dma.o
615 9 1 1573 -1 ^ CC Dma.c^ cctc.exe -co -o
Dma.o Dma.c
616 9 4 1411983374 9 DMA.out
617 9 4 1411983374 9 DMA.mdf
618 9 1 503 -1 ^ LI DMA.out^ cctc.exe -cl
-o DMA.out Dma.o
Cygwin stat:
2014-08-29 13:52:31.765693400 +0200 1409313151 Dma.c
2014-09-29 11:18:50.212643000 +0200 1411982330 Dma.o
2014-09-29 12:45:11.268592700 +0200 1411987511 DMA.out
2014-09-29 12:45:11.278592900 +0200 1411987511 DMA.mdf
==> Any ideas what could be wrong? Or any pointers to the tup source where I
could start looking around?
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.
