Solution to software packaging?

[Чебурашка]

I start saying that I am using the word "package" without assuming that the solution to this problem has to be use packages in the FPC/Lazarus sense. Let us say that I intend "package" in the common people's meaning, a sealed box containing things to form something deliverable as a whole.

I have a folder containing multiple units shared among many projects. It is not a big mess but I feel it could become.

Every time I build a project that uses units from previous folder I also build these files even if unchanged.

I would like to reorganize the things into "packages to obtain:

• Each "package" will contain only related units, and it will somehow define one or more dependencies to other "packages"
• Each "package" must be self buildable, i.e. I must be able to compile it as unrelated to the projects that use it
• When a project uses a "package" it will recompile the units in the "package" only when they are changed (recursively to the depenencies

What should I use to obtain this?

[wp]

• Each "package" will contain only related units, and it will somehow define one or more dependencies to other "packages"
• Each "package" must be self buildable, i.e. I must be able to compile it as unrelated to the projects that use it
• When a project uses a "package" it will recompile the units in the "package" only when they are changed (recursively to the depenencies

What should I use to obtain this?

Lazarus packages - they are exactly what you require.

• Create a folder for the units which will be contained within the same package.
• One important criterion is: Split units with designtime code (component registration, component and property editors, palette icons) off into separate "designtime packages"
• When a package needs a unit from another package do not add the path to the other package to the "unit path". Rather than that, add the other package to the "requirements" which you see as second node in the file tree of the package (and project) inspector.
• Likewise with a project: Do not set the "other units files" path to point to the location of the package units, but add the packages to the project "requirements".

Look at the attached screenshot taken from a demo project of the JVCL library. The project "JvComboListboxDemo" requires the packages LCL and JvCtrlsLazR. JvCtrlLazR contains a variety of units, among them the JvComboListbox.pas needed by the project. This package itself depends on other packages: FCL, JvCoreLazR, and JvStdCtrlsLazR, JvStdCtrls itself requires FCL and JvCoreLazR again. The screenshot lists also the designtime package belonging to the JvCtrlLazR runtime package. In particular, it has the runtime package in its requirements.

JVCL is a large library containing more than 150 units (in the Lazarus port). However, these units normally will not be compiled during application development (only when one of the JVCL units or a related compiler setting changes).

[Чебурашка]

Lazarus packages - they are exactly what you require.

First of all, thanks for the reply.

One more question.

Imagine I have arranged the software modules into packages, also setting the dependencies in the good way you recommend. Due to how I work there are many situations in which I do not use Lazarus for building: basically to develop I always use Lazarus (develop/build for verifying and debugging actually, but not for release and creating distribution bundles), to build for release I use always lazbuild. Is still Lazarus packages fine for working with lazbuild instead of Lazarus? I guess yes as my understanding is that building with lazbuild is about the same as doing it with Lazarus, but I prefer get a confirmation.

Thank you.

[wp]

yes