Possible bug: manifest generation with VS
Okay, I'm posting this here as I'm not sure it's a real bug yet, but here we go:
I'm seeing a failure to rebuild applications (specifically the manifest/resource compile stage) if I move around my tree and run jam. The tree has SubIncludes from the root down to the application that should mean that building from any directory should have the same effect, and it does (mostly).
E.g. with a Jamfile in the root folder which SubIncludes a Jamfile in the sub-folder that builds an application.
t:\> jam t:\> cd pong t:\pong> jam
The second instance of jam will fail to build.
It looks like a problem with the intermediate generated .rc file. The _writeManifest rule generates a $(TARGET).embed.rc file, and writes within it a path to the $(TARGET).embed.manifest file, relative to the current directory. When you change folders, the path that needs to be within that file changes, but because the .rc file still exists it is not recreated with the correct path, and the resource compiler fails to find the manifest file.
E.g. building from the root folder will result in pong/obj/pong.exe.embed.rc containing the text pong/obj/pong.exe.embed.manifest. Building from the pong folder will result in pong/obj/pong.exe.embed.rc containing the text obj/pong.exe.embed.manifest. But building from the root folder first will leave the .rc file in place, and when building from the pong folder will result in the resources compiler looking for pong/pong/obj/pong.exe.embed.manifest which of course doesn't exist.
I'm thinking that the .rc file should always be rebuilt, whether it exists or not, but I'm not sure how to patch the Jambase to achieve this.
I hate to leave this one hanging for so long. I just haven't had a chance to write a repro. If you have a simple one to contribute (especially one that could fit in the tests/ directory), that would be great and make it easier to fix and to continually verify it continues to work.
Sorry for the long delay in replying, this work fell to the bottom of my pile and has taken a while to resurface. I had a repro case but lost it, so I've knocked up this case to fit in the tests folder.
I think the cause of this may be related to your reply to my original thread here, in that using absolute paths for source files is causing issues when using the outputastree functionality. I'll get latest on the outputastree example and try to apply the logic their to our code-base
manifest_generation.zip - T:\jamplus\tests (1.48 KB)
I have added the manifest_generation to the tests/ folder.