I have a simple CMakeLists to compile detours express
project(detours)
add_library(detours STATIC detours.cpp disasm.cpp image.cpp modules.cpp creatwth.cpp)
file(COPY detours.h detver.h DESTINATION ${CMAKE_BINARY_DIR}/include)
The necessary flags are set in an upper level CMakeLists
add_definitions(-DDETOURS_X86 -DDETOURS_32BIT)
SET(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} /FS")
SET(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} /FS")
Yet when trying to compile a debug build each .cpp file after detours.cpp throws
FAILED: C:\PROGRA~2\MICROS~1.0\VC\bin\cl.exe /nologo /TP -DDETOURS_32BIT -DDETOURS_X86 -Iinclude /DWIN32 /D_WINDOWS /W3 /GR /EHsc /FS /D_DEBUG /MDd /Zi /Ob0 /Od /RTC1 /showIncludes /Foext\detours_express_3.0\src\CMakeFiles\detours.dir\modules.cpp.obj \Fdext\detours_express_3.0\src\CMakeFiles\detours.dir\ /FS -c ..\ext\detours_express_3.0\src\modules.cpp ..\ext\detours_express_3.0\src\modules.cpp : fatal error C1041: cannot open program database 'z:\repo\src\ext\detours_express_3.0\src\cmakefiles\detours.dir\vc120.pdb'; if multiple CL.EXE write to the same .PDB file, please use /FS
If I re-run ninja detours then the same happens with the next 3 cpp files, then the next 2, then the last, then the project is fully compiled.
If I run ninja -j1 detours then there are no issues, since I just disabled parrallel builds.
Why does it seem to be ignoring my /FS option? I'm using Visual Studio 2013.
Update 1
This is inside a VM in Virtualbox 4.3.10 with Guest Additions. Z:\ is a shared folder that I mounted. I've made sure to disable Windows Defender in the VM and the host, and uninstalled the third-party AV on the host.
Update 2
I found a workaround that avoids the symptoms and added it as an answer, but it still doesn't explain why /FS isn't actually synchronizing the locks.
/FSflag automatically (just before-c). Similar question: stackoverflow.com/questions/20643370/…. Probably, some external process locks your.pdbfile. What kind of drive isZ:/? - Tsyvarevdetours.dirfor example, and in this case I'm only compiling one project. It looks like the .cpp files are fighting over the .pdb, which would make sense since they'll all belong to the same executable later. I've tried searching for handles with ProcessExplorer while compiling but haven't had luck yet. - clark