[lazarus] Package System

Michael.VanCanneyt at Wisa.be Michael.VanCanneyt at Wisa.be
Sun Feb 2 12:01:46 EST 2003




[cut]
>
> Installing a package:
> Because fpc does not fully support libs, we can't add/remove components at
> runtime. We have
> to restart the IDE. Gladly lazarus starts a lot quicker than Delphi. The
> installation itself is done internally by adding the package unit to a uses
> section. The IDE will have dialogs and will handle most of this
> automatically just like Delphi.
> For example:
> To install a package the following five steps are needed:
> Open a package file, compile it, install it, compile IDE and restart.
> Normally a user will simply open the package file and click 'install'. The
> IDE will automatically compile the package, then ask the user if the IDE
> should be recompiled. After that the IDE gives a note, that the user can now
> restart the IDE.

1. Note that under windows the compile will fail, because a running binary is
   locked by windows.

2. It would be a good idea to have most IDE units in compiled form on a
   separate location, to speed up compilation.

>
>
> =============================================
> Projects will get 'package dependencies'. This is simply a list of package
> names plus minimum versions.
>
>
> =============================================
> Missing points:
> - design time / run time packages. Do we need this distinction?

_Absolutely_
I have gained lots of experience with packages at work, and you should
definitely make the distinction. Not only because users are forced to make
a clean design, but also because it makes run-time binaries smaller.
You wouldn't want half of lazarus ending up in a user binary...

> - component icons: The current solution is to add a lazarus
>   resource with the classname.
>   Sufficient? Or is the risk of redefinition too big?

Sufficient, Delphi uses this too.

> - Naming. For example: Maybe 'package dependencies' is not as
>   readable as 'package requirements' or 'required packages'.
> - IDE front end

You mean a kind of 'Open Tools API ?'

Michael.






More information about the Lazarus mailing list