1

I have a C++ project for which I need to run a custom build tool on some header files to generate code that is required when compiling this project. In general my configuration works. I trigger a build, VS/MSBuild detects whether the output files are up-to-date and runs the custom build tool only if necessary.

However, a problem arises if the build is run in combination with another configuration of the same project. Both configurations depend on the output files of the custom build tool. So if run sequentially only one configuration should trigger the custom build tool to run. For which ever configuration a build is triggered second the output files of the custom build tool are already present and up-to-date. So there is no need to build them again. Unfortunately this is exactly what is happening. Since the custom build tool takes quite some time to run, this increases build times dramatically. Another interesting aspect is, that once both configuration have run, I can trigger any of them again and the custom build tool is not invoked.

What I would have expected from the documentation is that the custom build tool is triggered:

  • If any of the files specified as Outputs is missing
  • If the file for which I specified the custom build tool was modified later than any of the existing files specified as Outputs
  • If any of the files I specified as Additional Dependencies were modified later than any of the existing files specified as Outputs

But all of this independent from the configuration for which the build was triggered.

Does anyone have an idea on why this might happen? I checked that the settings for the custom build tool are identical for both configurations. The output files are generated into the same folder for both configurations.

sigy
  • 2,408
  • 1
  • 24
  • 55
  • Make it reproducible easily and then report to Microsoft via Microsoft Connect or MSBuild GitHub repo. – Lex Li Feb 25 '16 at 11:04
  • 1
    The files VS uses to track what is up to date and what not by default go in per-configuration directories, so as far as VS in concerned the output files are different even though they are in fact in the same directory. See [Related](http://stackoverflow.com/questions/35107313/how-does-visual-studio-know-my-project-is-up-to-date-so-it-can-skip-running-msbu/) question/answer. You don't say what should trigger the custom build though. If you add that to the question, as well as a minimal sample, maybe someone can come up with a workaround. – stijn Feb 26 '16 at 08:33
  • Are you saying that the documentation (https://msdn.microsoft.com/en-us/library/hefydhhy.aspx) is wrong? I will update my question as requested... – sigy Feb 26 '16 at 08:44
  • @stijn Your hint with the *.tlog files helped a lot! I configured both configurations to use the same **Intermediate Directory** so that the *.tlog files go to the same directory and can be "reused". In my case it should not cause any interference since only one of the configurations does generate files other than *.tlog there. This workaround is not perfect though, because in fact I have 3 configurations in total, not 2. So only one of them benefits from it. However, if you want to convert your comment into an answer I would be happy to accept it. – sigy Feb 26 '16 at 11:25

1 Answers1

1

The documentation you're referring to is basically correct but it omits to say that everything in there is basically per project configuration/platform because it uses tracker.exe which depends on .tlog files which by default go into the intermediate directory. So as you figured out, making all configurations use the same location for the tlog files should keep the tracker happy and only invoke the custom build tool when needed, independent of configuration/platform. I'm not sure I'd recommend any of this though, sharing temporary object files might cause you problems later.

Another way to deal with this is adding a seperate project with just one configuration, say 'Custom', and do the custom build there. Than make your current project(s) depend on that project and in the solution's Configuration Manager adjust all entries so each configuration you have now builds the 'Custom' configuration for the new project.

stijn
  • 34,664
  • 13
  • 111
  • 163
  • In my case the configuration which should 'reuse' the results of the custom build tool of the other configuration(s) does not produce any temporary object files. Therefore I consider it reasonable save since no files other than *.tlog will be shared. Your remark on this topic, however, is correct. – sigy Feb 26 '16 at 13:51