Manage Reusable Procedures by Including Source vs Compiled Modules

How to manage FreeBASIC reusable procedures by including source modules 
versus including compiled modules.
(written with help of Josep Roca's posts)

Preamble:

   When old OSs (like DOS) were used, compiling by separate modules was 
   mandatory as soon as the program was not very short, because of the 
   small memory size available for the compiler (about 200 KB with Quick 
   Basic 4.5).
   Now, with modern PC and OS, this compilation limit is pushed back by a 
   factor of about 10000, and the compile time for a large file in one go 
   has become acceptable especially with FreeBASIC.
   This allows to use another method (than a library of compiled files) to 
   manage the reusable user procedures.

   First, the reusable user procedures source codes are grouped into 
   different source modules, for example by functionality.
   Then the process is different depending on each method used.

   To simplify the explanation that follows, it is considered that there is 
   only one source file containing the main program, which calls the 
   various user procedures contained in source modules for reuse.
   But one can easily complete these methods to take into account a main 
   program spread over several source files.

First method: The compiled modules stored in a library file are included in 
the linking process with the compiled main program
   The principle of this method is by only accessing to the compiled user 
   procedures.

   The different modules (containing the sources of the user procedures to 
   be reused) are turned in to object files and then stored into a library 
   file (using the -lib compile option).
   Finally the source file of the main program is compiled, then linked to 
   the library, to make an executable (using the -l < libname > compile 
   option, or the #Inclib "Libname" directive put at beginning of the main 
   program source code).

   For each compiled module, if at least one procedure is called, then the 
   entire module will be added in the final executable.

   Thus, the granularity of the added code to the executable is at the 
   module level (coarse granularity).

Second method: The source modules are included directly in the main source 
program to be compiled in one go
   The principle of this method is by fully accessing to the sources of 
   user procedures.

   The different modules (containing the sources of the user procedures to 
   be reused) are directly included in the source of the main program 
   (using the #Include "File" directive for each module, put at the 
   beginning of the main program source code).
   Finally, the big resulting source file is compiled in one go to make it 
   an executable.

   Since the compiler processes a single source file, all reusable user 
   procedures can be declared as Private (which is obviously impossible 
   when using library because the external links are required during the 
   linkage).
   As a result, only the Private procedures really called will be kept in 
   the executable.

   Thus, the granularity of the code added to the executable is at the 
   elementary procedure level (fine granularity).

   Note:
      The compiler removes the Private procedures that are not called, but 
      this does not currently work for Private procedures that are only 
      called by other Private procedures that are not called themselves, 
      because the first ones appear as being called.
      The problem is that the one-pass compiler only uses a simple flag to 
      track the "used" state of a procedure, which is set whenever the 
      procedure is accessed, no matter from where.

See also
   * fbc command-line
   * Source Files (.bas)
   * Header Files (.bi)
   * Using Prebuilt Libraries	

