Windows Ninja build: cannot open file 'bin\*.ilk'

[sadguitarius]

Hi, I was just trying to build the library with examples on Windows using Ninja, and ran into these errors:

cannot open file 'bin\d_embed_external_ui.ilk' (and similar errors for other targets)

The errors show up for different, and not all, targets for each build, and eventually the build will succeed after a few tries.

I've traced it back to this discussion, specifically the part about projects configured to write to the same .ilk file.

Lo and behold, I changed the OUTPUT_NAME variables in DPFPlugin.cmake so the each target has its own unique name, and this did solve the problem.

I also don't have the problem when disabling parallel builds in Ninja, which seems to confirm that this is some kind of file access race condition. Obviously though, this defeats the purpose of using Ninja to speed up builds.

The only drawback I can see is that the binary names are changed. I'm not much of a CMake wiz, so beyond diagnosing this issue, I'm not sure of the best way to solve it and keep the resulting filenames the same.

Ninja really is way faster for Windows builds (and probably non-Windows too), so it would be nice to get this working properly!

[falkTX]

each target already has different names though? like $plugin-ladspa.dll and $plugin.dll for vst2 and $plugin.clap etc...

first time I hear of this, pull requests are welcome, discussion can be on top of that too.

[sadguitarius]

what I'm referring to is, e.g.

  set_target_properties("${NAME}-vst3" PROPERTIES
    ARCHIVE_OUTPUT_DIRECTORY "${PROJECT_BINARY_DIR}/obj/vst3/$<0:>"
    OUTPUT_NAME "${NAME}-vst3"
    PREFIX "")

instead of

  set_target_properties("${NAME}-vst3" PROPERTIES
    ARCHIVE_OUTPUT_DIRECTORY "${PROJECT_BINARY_DIR}/obj/vst3/$<0:>"
    OUTPUT_NAME "${NAME}"
    PREFIX "")

I'm happy to make a PR for this and we can see how things go with that. Thank you!

[sadguitarius]

oh and it's possible that the problem is only happening for certain output types, so I can try some different combinations to see exactly where it's breaking.

[falkTX]

ah but we dont want that change I think, makes things quite ugly just so we can workaround a limitation somewhere else...

seems to me this builder combo is storing temporary files in a common location based on the OUTPUT_NAME variable.
that just seems wrong to me.
a better approach would be to set some other property that we know is being read by this builder combo that would workaround the issue, without having to affect other build systems.

[falkTX]

I mean in the same way there is ARCHIVE_OUTPUT_DIRECTORY there might be similar variables here.

[sadguitarius]

agreed, and that is the kind of solution I'm hoping for as well.

[sadguitarius]

Looks like it's the CLAP and .exe targets that are conflicting with each other since they have the same binary output directory. There is a CMake PDB_OUTPUT_DIRECTORY variable but I'm not sure about the .ilk file location. I believe that .pdb files should be located in the same location as the files they refer to though. Would it be acceptable to change the directory heirarchy so that CLAP outputs go to a different location from .exe?

[sadguitarius]

fyi I tried disabling incremental linking so that .ilk files are not generated but then the linker starts complaining about .pdb files. oh well.

[falkTX]

Looks like it's the CLAP and .exe targets that are conflicting with each other since they have the same binary output directory. There is a CMake PDB_OUTPUT_DIRECTORY variable but I'm not sure about the .ilk file location. I believe that .pdb files should be located in the same location as the files they refer to though. Would it be acceptable to change the directory heirarchy so that CLAP outputs go to a different location from .exe?

maybe just disable the standalone for now?

I dont like things going into separate directories.

[sadguitarius]

Yeah that works. I think it's only an issue for debug builds anyway.