[fpc-devel] Delphi-like Packages, Plan

[Marco van de Voort]

In our previous episode, Willibald Krenn said:
> Here comes my 'official' plan on how I want to implement Delphi-like 
> Package Support for FPC on Win64. Feel free to comment.
> 
> 
> 
> Definitions
> ~~~~~~~~~~~
>          <File>.ppl      Free-Pascal Package Library
>                            (shared module, Delphi: bpl)
>          <File>.ppk      Free-Pascal Package
>                            (source, Delphi: dpk)
>          <File>.pcp      Free-Pascal Compiled Packge
>                            (header, ppu's, Delphi: dcp)
>          (skip package collections for now)
> 
>          -K <File>[ <File>]*
>                          Command line arg to tell fpc to compile
>                          program/dll with runtime package support.

- is it really necessary to change extensions to ppl/ppk ? These formats are not
  compatible between Delphi anyway.
- dcp can also contain implementation part of .dcu which is .o in FPC.

> -> M1
> ~~~~~
> Goal:   - Compile System unit into a "fpcrtl.ppl"
>          - Create a simple application that uses fpcrtl.ppl.
>            -> Perhaps some simple string sorting program.
           
          - in a systematic way without any duplicate state or manual
                 intervention

If too difficult, break up M1 in multiple milestones. But the fact that the
division is wholly automatical (given the same input data as delphi, so a
dpk/dpr and a few settings that signal "build with package x,y,z) is crucial
for packages.

That is also more important packing everything in .ppk's exactly like
Delphi. 

A solution could be to give .ppu's (and .o's if necessary) a different
extension if generated as part of a package system.

>        Add command line parameter (-K) so that applications can be
>        compiled with packages. Change pmodules.proc_program to pre-load
>        all units of all referenced packages.

You will need an additional parameter to specify from which compiled packages
(.dcp's) .ppu's  must be preloaded.
 
If sufficient clean and doable, this might already be a good point to merge
into the trunk.

But the main point of packages is total control (and thus checking) by the
compiler, not "just having something dynamic".