How to determine why a module compiles when building a DLL

questions
1

I have a solution with an APP, let’s call ClassApp, that includes and export a number of classes.
A particular class module that is not part of ClassApp compiles when I compile that app.
This class, let’s call Class1, is not “included” in ClassApp.
I’ve tracked down where Class1 is used. It is used in 2 other classes (and some other APPs). These 2 classes are not used in any other classes, only in other APPs. These other classes are also not in ClassApp.
Class1 is not in ClassApp.cwproj
Class1 is not in the MAP for ClassApp. I also added a specific literal string to Class1.clw. When I search ClassApp.DLL I do not find the string literal. This leads me to believe Class1 is not actually in ClassApp. Its module is just being compiled.
Is there anyway to determine what is causing Class1 to be compiled when ClassApp compiles? @anon77170705 I thought you might be able to shed some light on this.

2

CLASSes in the MAP structure are not allowed.

This tells about nothing if that string is not used.

Files to compile are determining by the Project Manager. Initially, these are files listed in the project file. When a file compiled without errors, the Project Manager parses produced OBJ files for specific records containing names source/OBJ/LIB/resource files referenced in the compiled source (including all the tree of its INCLUDEs). Source files are adding to the compile list. Resource files are adding to the link list. OBJ and LIB files are parsing if they have not been parsed yet, etc. recursively.

So, grep OBJ/LIB files for the name of Class1 to find where it is referenced.

3

I’m assigning the literal to a class property. I confirmed this idea would work by putting a similar string into a class that is included in the APP and I find that string when searching the binary DLL.

I’m not sure what you mean by this. Searching the APPName.MAP definitely finds references to the classes compiled and export from that APP/DLL. There are CLASSNAME_DATA, CLASSNAME_TEXT, CLASSNAME_CONST entries and all of the class methods are listed in the map.

4

Turns out there was an include statement for a non-member class in the global module for ClassApp. Let’s call this Class2.
Class2 included some classes that were member classes of a different APP/DLL than ClassApp.
These classes had MEMBER(‘APP2.clw’) statements.
All of the classes referenced in APP2.clw were being compiled when compiling ClassAPP even though ClassApp didn’t use any of those classes from APP2.
Removing the include statement for this non-member classes resolved all of the compile problems.

1 Like