Compiling using VS tools and Tup build-system

Question

I am trying to compile an interpreter for the J programming language called "unbox" which can be found at: https://github.com/iocane/unbox

It uses the tup build-system and the github instructions specify to use the tup command from the Visual Studio tools prompt. I downloaded Visual Studio 2015 Community but it doesn't come with the exact prompt mentioned in the instructions so I used the VS2015 x86 x64 Cross Tools Command Prompt. After installing tup and adding it to my path, I navigated to the directory where I cloned "unbox" and typed tup.

However, this is where the problems start, after typing tup I get the following:

*   1) CC src/libj\a.c
a.c
 *** tup errors ***
tup error: File 'C:\Users\I\AppData\Local\Microsoft\VSCommon\14.0\SQM\VCToolsTelemetry.dat' was written to, but is not in .tup/db. You probably should specify it as an output
 *** Command ID=663 ran successfully, but tup failed to save the dependencies.
*   2) CC src/libj\af.c
af.c
 *** tup errors ***
tup error: File 'C:\Users\I\AppData\Local\Microsoft\VSCommon\14.0\SQM\VCToolsTelemetry.dat' was written to, but is not in .tup/db. You probably should specify it as an output
 *** Command ID=667 ran successfully, but tup failed to save the dependencies.
*   3) CC src/libj\ai.c
ai.c
 *** tup errors ***
tup error: File 'C:\Users\I\AppData\Local\Microsoft\VSCommon\14.0\SQM\VCToolsTelemetry.dat' was written to, but is not in .tup/db. You probably should specify it as an output
 *** Command ID=669 ran successfully, but tup failed to save the dependencies.
*   4) CC src/libj\ab.c
ab.c
 *** tup errors ***
tup error: File 'C:\Users\I\AppData\Local\Microsoft\VSCommon\14.0\SQM\VCToolsTelemetry.dat' was written to, but is not in .tup/db. You probably should specify it as an output
 *** Command ID=665 ran successfully, but tup failed to save the dependencies.
 [                                        ETA~=30s Remaining=130 Active=0                                        ]   2%
 *** tup: 4 jobs failed.

As you can see, the file VCToolsTelemetry.dat was not specified in tup's database.

Does anybody know a way to prevent Visual Studio from using VSToolsTelemetry.dat at all? Or should I contact the unbox developer and have him add that file to the db?

Any help is much appreciated.

Answer 1

The solution was given by Christian Fillion in this comment.

---

This Microsoft page explains what that file is for and how to prevent Visual Studio tools from writing to it:

By default, the Visual Studio installation enables customer feedback. You can configure Visual Studio to disable customer feedback on individual computers by changing the value of the following registry key to string "0".

The key referred to is OptIn. According to that page, it is located in HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\VisualStudio\SQM, although it could also be in HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\VSCommon\14.0\SQM (this was the case in my Windows 10 laptop).

(The Microsoft page also says it should be a string, but in my case it's a DWORD and it works fine.)

---

Or should I contact the unbox developer and have him add that file to the db?

What's happening is that Tup, a file-based build system, requires that all outputs of a command be specified, but this file is not, and so Tup complains when it detects that it's written to. For Tup, there is no difference between creating and writing to a file — in both cases, it's an ‘output’. Thus, Tup doesn't handle situations in which several commands write to the same file. This often causes problems with caches, which are designed to be written to incrementally. If I recall correctly, Tup has a workaround implemented whereby it ignores output files whose path comprises any component with a leading period. In Linux environments, a directory whose name starts with a leading period is considered ‘hidden’, unlike in Windows, where this feature is implemented with a file-system attribute. This workaround thus generally fails with Windows native tools, which don't rely on such naming convention. A more flexible solution on Tup's side would be a way of telling Tup to ignore certain outputs, either in a system or user basis or from within Tupfiles.

It wouldn't be possible to list this file as an output because it would become an output of all invocations of CL.EXE (and possibly other Visual Studio tools), and this doesn't make sense per Tup's design. There's definitely no intention to make room in it for files which are read from and written to by the same command, since it's impossible to automate such scenario. Even if this file was only written to, I think there are no intentions to support incrementally-written outputs.

Since the project seems to be committed to some platforms and provides build instructions for them, it seems reasonable to point out the issue and the solution to them so they can include it in the instructions.