Best Way to replicate ClCompile/Link targets to elimiate to eliminate 2 pass Msbuild VS2019 plugin

Question

I am trying to eliminate a Visual Studio 2019 plug in which triggers a second MSBuild pass.

Given: A build flow where a custom build task creates *.cpp modules from *.bla files. These are then linked with other *.cpp modules to create an EXE.

The informaiton needed to process *.bla files requires that the resulting exe be run. A true chicken and egg problem. The current solution is that the custom task detects when the exe does not exist, and creates stub version of the .bla->.cpp task, which are then used to allow the linker to resolve symbols and create a "stub mode" exe. The current Visual Studio plug-in detects when the stub was created and triggers a second run through the build so the bla processor can run the exe to provide data needed to process bla files properly. Sounds like fun right?

Today we go from *.bla -> *.cpp -> *.obj and the *.bla items are just merged into the @(ClCompile) item list. @(blaItems) -> @(CppBlaItems) added to @(ClCompile) Pass one creates a STUB user.exe which is then used by the "bla" file task in the second pass.

All of this was created initially back in Visual Studio 6.0 days. Then ported to VS2013 and later VS2019. The plug-in technology and build technology has improved to the point I believe MSBUILD is sophisticated enough to elminate the plug in.

But MSBUILD has a rule that a target is executed only once.

So I need to create new targets that replicate the ClCompile and Link target behavior on the .bla->.cpp->*.obj

I've gotten a .targets/.xml/*.props trio about 80% of the way but don't know the best way to replicate ClCompile/Link.

At the moment I'm thinking just make new targets BlaStubCompile BlaStubLink and import the files that ClCompile and Link have imported. But I'm not sure this is a good idea. Thats the path I'm going to investigate today. Thought I would reach out to see if I'm missing some intuitively obvious alternative solution.

Answer 1

If possible I would avoid replicating the Microsoft provided ClCompile and Link targets because the targets are subject to change without notice. The risk of an issue from this is small but the risk can be zero if you are not maintaining your own copies.

In the Remarks section of the MSBuild task documentation is the following note:

Unlike using the Exec task to start MSBuild.exe, this task uses the same MSBuild process to build the child projects. The list of already-built targets that can be skipped is shared between the parent and child builds.

A possible approach then is to have a Target that runs if the "stub mode" exe does not exist and the target would use an Exec task to run MSBuild on its project to build the "stub mode" exe. Because it is a separate process, the list of already-built targets will not be shared with the parent build.