Post build step fails because build isn't finished

[cacb]

This relates to Code::Blocks nightly build svn 13319 under Win10.

I am using my own C::B configuration of the MSVC compiler (from MSVC 2019), and it all works fine most of the time. I am running the same setup on 2 different Win10 machines, where one is rather old and slow. All works fine there. On the newer, faster machine I am seeing intermittent issues with C::B post build steps.

I am running the following post build step always
mt.exe /nologo /manifest $(TARGET_OUTPUT_FILE).manifest /outputresource:$(TARGET_OUTPUT_FILE);1

Sometimes (not always), the following happens on the faster machine:

Running target post-build steps
mt.exe /nologo /manifest .cmp\msvc\bin\Release\fftgui.exe.manifest /outputresource:.cmp\msvc\bin\Release\fftgui.exe;1
C:\source\cpde_usr\bin\cpde_usr -bin -xi -project=fftgui  -root=C:\source\cpde_git\srt\FFU\fftgui\  -build=MSVC_Release  -target=.cmp\msvc\bin\Release\fftgui.exe  -usr=C:\source\cpde_usr
mt.exe : general error c101008d: Failed to write the updated manifest to the resource of file ".cmp\msvc\bin\Release\fftgui.exe". The process cannot access the file because it is being used by another process.


The problem seems to be that the Code::Blocks post build step sometimes runs the post build step with MT.exe before the main build target file is closed by the compiler/linker. When it happens the whole workspace build sequence stops.

Is there a way to guarantee a post build step does not start before the $(TARGET_OUTPUT_FILE) is closed?

[sodev]

I recall having that problem as well in the past, i'm afraid you are pointing your fingers at the wrong dude: it's not CodeBlocks but Windows (Defender?). From my notes, this problem happened only sometimes and all tricks trying to delay the run of mt.exe by using WAIT commands or Windows cmd tricks using TIMEOUT and PING did not work.

I solved the issue for me by not using mt.exe to get the manifest into the executable but using the compiler directly with the options /MANIFEST:EMBED /MANIFESTINPUT:<my.manifest>.

[cacb]

Thank you for the reply! I have checked your idea.

It seems the options  /MANIFEST:EMBED /MANIFESTINPUT:<my.manifest> are not compiler options, but /MANIFEST:EMBED is a linker option.
I saw no use for MANIFESTINPUT:<my.manifest>.

The idea to use /MANIFEST:EMBED as a linker option is a good one, but it does not address the problem reported regarding C::B post build steps:

As you can see from the image attachment of my first post, I did run 2 post build steps. The first was MT.exe, the second is a utility 'cpde_usr' I have written to export header files etc. to an external folder structure. After eliminating MT.exe as a post build step, I am now experiencing that my own utilty cpde_usr is failing for the exact same reason: The post build step is being executed before the build target is ready (i.e. build target file is not closed).

I still think this is a C::B problem related to post build steps in general. If I run 'cpde_usr' manually after, it works fine with the same input.

[sodev]

Ok, so you eliminated one step that accesses the file but still have another step left .

I did not really figure out what was locking the file, but im quite sure it happens after the compiler/linker finished, so there is not much that CodeBlocks can do. You could add the build directory to the Windows Defender exclusions and check if this makes a difference. Otherwise you either use other monitoring tools to figure out actually who is locking the file, or, if you have control about your post-build step, maybe let it ignore that specific error and try again.