>>>How do you tell VFP to NOT scan the project looking for dependencies that it then automatically adds to the project?
>>>
>>>If you have one class or reference in the wrong place and you try to build a small little project VFP ends up finding that reference and ends up pulling code from other projects into this project. It's very handy behavior most of the time, but sometimes it's a giant PIA.
>>
>>That's one of the major reasons I recommend not putting multiple udfs/procedures into .PRGs nor multiple classes into a single classlib. Seriously, think about it this way - the blueprints for a car, do not get sold with the car. Our work is all blue prints. The final exe does not care how the source is organized.
>>
>>By having a library.prg with several routines in it, when you need 1 routine, the whole thing gets built into the exe/car. Who thinks that's wise/practical regardless of the "that's the way we've always done it".
>
>Part of the confusion is likely how terminology is used. In other language systems, for example in C, you would normally have separate source files for each of the functions (in cases where you have interrelated functions that are *always* used together, you might combine them in a single source file). Compilation of individual source files generate individual object modules (e.g. .OBJ files). The librarian software is then used to construct the separate library files (which is basically a convenient method of gathering related program modules together into a single location). The linker software is used to combine the specified individual object modules, along with any required ones from the libraries to combine to create the final load module (e.g. .EXE file).
>In VFP, "function library" is used, wouldn't be considered a real "library" in the same sense. It refers to collecting items at the source level that produces a single "chunk" that can't be broken out into parts. If I'm not mistaken, the entire class library is brought in -- much like a single PRG file. The upshot of this is that if you want to minimize the "footprint" your program, you have to separate the components into individual parts at the source level. This means you probably want to limit the number of classes per VCX to only a handful at most (that is if these are classes that are always going to be used together), and function libraries should be broken up into individual PRGs. Unfortunately the result of this would be that you could end up with a large number of individual PRG/FRX, and VCX files in a single project, which is rather inconvenient.

It's equally inconvenient to know a class or udf's name and not being able to find it without searching through several containers. VFP itself does not require me to set procedure to datelib, before I can ?date().

The only reason to collect things into a single prg was to provide support for longer names - back in the old fox and the 8.3 days. Since most programmers abbreviate the heck out of things, the practice is laughable. Teams of programmers cannot work on single large libraries or classes at the same time. That's got to be a huge productivity hit. Sharing a library with another developer is the only advantage which should not be a consideration when the end product is the exe.

> For the convenience of having individual functions and classes into only a handful of "library" files is eventual bloat.
>Granted, if you look at earliest example of use of term "library" it typically meant a group of routines that were brought in (in their entirety). Likewise the original term usage of "compiler" is more like the modern usage of the term "linker" -- though this usage was back when most programming was done at the machine code level rather than HLL.

Yes. Understood.