Bernhard, Thank you for your reply. You are correct, for the reasons you explained, TUP is not able to monitor file operations of 64-bit processes. This is a serious bug since I cannot guarantee that I will never need to invoke a 64-bit process.
For me, one significant advantage of this build system is that it can produce provably correct builds. Such a build system should not have a blind spot to a subset of file operations, in my humble opinion. When is this bug expected to be fixed? I will re-post my feedback on the example in another thread. At the very least, the example should behave as the example claims it will. Cheers, Ben On Tuesday, October 7, 2014 7:26:53 AM UTC-7, [email protected] wrote: > > > From: Ben Robinson [[email protected] <javascript:>] > > 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.
