I need help deciding how to best manage a static library when some of the routines use a dialog resource.
For my individual applications that use a dialog, I usually place all three dialog files (resource file PROG.RC, Fortran include file RESOURCE.FD, and C include file RESOURCE.H) in the same folder as the source PROG.F90, and add RESOURCE.FD to the project using Visual Studio. The include files become available to the project by virtue of the default search location for includes, which is the same folder as the source. So far so good.
If I am working on a library project, I put all of the subroutine sources SUBnn.F90 in the library source folder. If subroutine 01 uses a dialog, then I put the associated SUB01.RC, RESOURCE.FD, and RESOURCE.H in the same folder, and add SUB01.RC to the project. This works fine too.
But what if two or more of the library subroutines use a dialog? I can name their resource file SUB01.RC, SUB02.RC etc., put all of them in the library folder, and add all of them to the library project. But the include files are problematic, since they have the same names by default. I can rename the Fortran include files SUB01.FD, SUB02.FD etc. because the Fortran include file needed for each subroutine is explicitly stated in the subroutine source. But that doesn't work for the C include files, RESOURCE.H, because this is specified inside the .RC file.
The only way I see to make this system work is to edit each .RC file to call for a custom-named C include file. That seems like asking for trouble.
Is this a good way to organize the library project? Can anybody suggest a better way?