> From: Ben Robinson [[email protected]] > Sent: Tuesday, October 07, 2014 1:08 AM
> Is there any progress on Windows64 support? I was working through the > examples on the website, and noticed that after adding unused.txt as an > input to the rule which produces output.txt, it does not appear correctly > in the graph of dependencies. I suspect TUP did not correctly detect the > file activity, due to my running on 64-bit Windows. As I understand it, the tup.exe from http://gittup.org/tup/win32/ is a 32-bit binary. This means on 64-bit versions of Windows it will run on top of the WoW64 layer (Windows 32-bit on Windows 64-bit), see http://en.wikipedia.org/wiki/WoW64. As long as your Tupfiles only call 32-bit programs you should be safe. I'm using the vanilla 32-bit tup.exe from v0.7.3-3 with a 32-bit tool-chain on Windows 7 Enterprise 64-bit without issues like yours. Tup monitors file accesses by injecting a special DLL into to the created sub- processes. Without changes to the tup code, using 32-bit tup to monitor 64-bit programs won't work. The same would be valid for 64-bit tup trying to monitor 32-bit programs. Both versions would fail to inject the DLL. I think what Robert tried to do, was to build a 64-bit tup.exe which would be able to inject the 32-bit version of the DLL into 32-bit programs and the 64-bit version of the DLL into 64-bit programs. If you want to see which file accesses tup is able to see, try something like "tup -d -j1". You should see many messages like this: "[tup.updater:6208 file.c:88] received file 'C:\data\Workspace\tup_example\output.txt' in mode 1" According to tup source code the numbers after "mode" signify the type of file access: 0 = read, 1 = write, 2 = rename, 3 = delete. > The online example claims that TUP will model this dependency, but because it > detected that the file was not actually read when evaluating the rule, it will > model it differently. See the attached PNG showing that TUP is unaware of the > unused.txt dependency on the rule. I'm not sure if the example at http://gittup.org/tup/ex_dependencies.html makes any sense. What you try to do is adding a generated file as an input dependency to a command which doesn't use this generated file at all. Why should tup care about this link at all? There can't be any effect on output.txt if unused.txt was changed. If on the other hand you changed test.bat to read from unused.txt you would have to add this new dependency on unused.txt. Tup will error out if you omit this. As soon as you add the new dependency tup will know the correct order of commands. I don't think this behaviour has anything to do with 32-bit vs. 64-bit Windows. 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.
