DFHack
Windows rebuilds fail after structure changes
If I build DFHack using one df-structures commit, then update it and attempt to rebuild, chances are fairly high that the rebuild will fail with "unresolved external" errors related to any structures that were modified. This happens especially frequently when new structures are added or old structures are removed.
For example, upon updating df-structures to commit 6415046c31c7a74aa227cae450d873a6b53ae660, a rebuild failed as follows:
w.obj : error LNK2019: unresolved external symbol "public: __cdecl df::world_unk_20::T_anon_7::T_anon_7(void)" (??0T_anon_7@world_unk_20@df@@QEAA@XZ) referenced in function "void * __cdecl df::allocator_fn<struct df::world_unk_20::T_anon_7>(void *,void const *)" (??$allocator_fn@UT_anon_7@world_unk_20@df@@@df@@YAPEAXPEAXPEBX@Z) [G:\dwarfort\dfhack\build\VC2015_64\library\dfhack.vcxproj]
w.obj : error LNK2019: unresolved external symbol "public: __cdecl df::world_unk_20::world_unk_20(void)" (??0world_unk_20@df@@QEAA@XZ) referenced in function "void * __cdecl df::allocator_fn<struct df::world_unk_20>(void *,void const *)" (??$allocator_fn@Uworld_unk_20@df@@@df@@YAPEAXPEAXPEBX@Z) [G:\dwarfort\dfhack\build\VC2015_64\library\dfhack.vcxproj]
w.obj : error LNK2019: unresolved external symbol "public: __cdecl df::world_unk_a8::world_unk_a8(void)" (??0world_unk_a8@df@@QEAA@XZ) referenced in function "void * __cdecl df::allocator_fn<struct df::world_unk_a8>(void *,void const *)" (??$allocator_fn@Uworld_unk_a8@df@@@df@@YAPEAXPEAXPEBX@Z) [G:\dwarfort\dfhack\build\VC2015_64\library\dfhack.vcxproj]
w.obj : error LNK2019: unresolved external symbol "public: __cdecl df::world_unk_b4::world_unk_b4(void)" (??0world_unk_b4@df@@QEAA@XZ) referenced in function "void * __cdecl df::allocator_fn<struct df::world_unk_b4>(void *,void const *)" (??$allocator_fn@Uworld_unk_b4@df@@@df@@YAPEAXPEAXPEBX@Z) [G:\dwarfort\dfhack\build\VC2015_64\library\dfhack.vcxproj]
w.obj : error LNK2019: unresolved external symbol "public: __cdecl df::world_unk_c0::T_anon_7::T_anon_7(void)" (??0T_anon_7@world_unk_c0@df@@QEAA@XZ) referenced in function "void * __cdecl df::allocator_fn<struct df::world_unk_c0::T_anon_7>(void *,void const *)" (??$allocator_fn@UT_anon_7@world_unk_c0@df@@@df@@YAPEAXPEAXPEBX@Z) [G:\dwarfort\dfhack\build\VC2015_64\library\dfhack.vcxproj]
w.obj : error LNK2019: unresolved external symbol "public: __cdecl df::world_unk_c0::world_unk_c0(void)" (??0world_unk_c0@df@@QEAA@XZ) referenced in function "void * __cdecl df::allocator_fn<struct df::world_unk_c0>(void *,void const *)" (??$allocator_fn@Uworld_unk_c0@df@@@df@@YAPEAXPEAXPEBX@Z) [G:\dwarfort\dfhack\build\VC2015_64\library\dfhack.vcxproj]
Just deleting w.obj was insufficient, as it would still generate another error likely because it hadn't rebuilt c.obj either:
w.obj : error LNK2001: unresolved external symbol "public: static class DFHack::struct_identity df::cursed_tomb::_identity" (?_identity@cursed_tomb@df@@2Vstruct_identity@DFHack@@A) [G:\dwarfort\dfhack\build\VC2015_64\library\dfhack.vcxproj]
In the distant past, we had the exact opposite problem where [a-z].obj and other.obj were being needlessly rebuilt, but whatever fix was applied only made things worse.
Building on Windows 8.1 using Visual C++ 2015 Community and CMake 3.18.2.
