Peter,

>>Then exchange classlib for program file in my previous message. It's still your problem from not having your program files granular enough.
>
>Once more: The problem already happens if only one program file refers to one other program file. How granular can one make it?!

Let me give an example of program packaging that causes extra code bundled into the project.

* AppA.prg
...
set procedure to Proc1

do B
return

* AppB.prg
...
set procedure to Proc1

do C
return

* proc1.prg

function B
do B1
return

function C
do C1
return

* B1.prg
set procedure to Proc2 additive
return

* C1.prg
set procedure to Proc3 additive
return

AppA and AppB are the main for two seperate projects. When you build either project these files will wind up inside them

ProjectA =
AppA.prg
proc1.prg
b1.prg
c1.prg
proc2.prg
proc3.prg


ProjectB =
AppB.prg
proc1.prg
b1.prg
c1.prg
proc2.prg
proc3.prg

ProjectA does not call C or C1 or need proc3.
ProjectB does not call B or B1 or need proc2.

But everything is included because of the "inappropriate" packaging of B and C into a single program file.

Now FoxPro can not do a complete call stack flow through the ProjectA to determine that C is not called and therefore everything along that chain is not needed. This is extremely impossible to do because we have the ability to use macros as well as indirect calls ala:

lcFunc = "c1()"

? evaluate( lcFunc )

function c1
return "c1 indirectly called"

which would require the project build process understand that the string "c1()" really does mean a function call.

If function B and C had been pulled apart into two seperate program files and AppA.prg and AppB.prg got rid of the now unnecessary SET PROCEDURE lines, then no unnecessary programs would be bundled into either project.

ProjectA =
AppA.prg
b.prg
b1.prg
proc2.prg


ProjectB =
AppB.prg
c.prg
c1.prg
proc3.prg