Ading to Manan:
ODFRC produces intermediate files which are later handled by merge_res.cmd and restore_res.cmd - they basically perform some copy tasks. These extra commands are invoked by pre-link and post-build events.
All of this is historically grown over two decades, and tied together with plenty absolute, and pseudo-absolute variables referring to places within / relative to the SDK. These variable are defined either thru .vsprops files and .rsp files, again with a quite grown structure. Redundant, competing, inconsistent.
As soon you move your project, all the references fall apart, point to wrong or missing folders.
So the simple solution is to keep your projects in the exact same build/win/prj folder that the SDK uses.
In the long run a solution could be: learn the project file formats, make a sense out of all the different approaches and oddities, and fix them. Want your project file with your sources, rather than within the SDK? Want your temporary build file outside the source hierarchy? You can do. Repeat with every SDK release, or write a script to perform the required steps. You may also discover references to missing include folders (causing slower compile times), or find it more convenient to compile multiple .fr files independently and only merge the results into a single plug-in, or rework structures in the official SDK projects that match the IDE of 10 versions ago, always lazily auto-converted while a modern re-build has a very different file layout. And so forth.
To get started with that process, put your project under source control. Do the changes one by one, and when it fails, rethink your most recent change. Consider every compiler error output even if it is hidden by the IDE. If this sounds like a lengthy process - yes it is. If you're planning to stay for many versions, write multiple plug-ins, it may be worth the effort.
10
Replies
AdChoices