[Lazarus] How to tell lazarus the location of a used package?

Bo Berglund bo.berglund at gmail.com
Thu Nov 25 12:09:16 CET 2010

On Wed, 24 Nov 2010 16:13:55 +0100, Mattias Gärtner
<nc-gaertnma at netcologne.de> wrote:

>Zitat von Bo Berglund <bo.berglund at gmail.com>:
>> On Wed, 24 Nov 2010 11:06:15 +0100, Mattias Gaertner
>> <nc-gaertnma at netcologne.de> wrote:
>> [...]
>> I am trying to get my head around this concept...
>> Currently we work in Delphi.
>> Say that we develop a number of different programs.
>> These programs have sourcefiles that are private to each.
>> But they also use common sources in various degrees.
>> We check out each project via CVS using modules definitions.
>> This way we get all needed sources including common ones into the
>> project folder in different subfolders.
>> The Delphi project file has search paths (relative) to these.
>> Now we can develop our program on differet workstations and check out
>> the same program sources several times if need be and all will work.
>> We also can make a change to common code that will not (yet) impact
>> any others using the same common code in another project.
>> At regulat intervals we tag from the top folder and after this we can
>> work onwards.
>> Using the CVS tags we can later return to exactly this place in time
>> for all of our files so we can reproduce a bug.
>So far this sounds pretty normal.
>> One of our big headaches in this scenario has been the custom
>> components that we (unwisely) created and installed in Delphi, because
>> the IDE could very well pick up code from the IDE tree rather than the
>> checked out code, which we want to keep very tight reigns on.
>> Now, the description on how packages work in lazarus leads me to
>> believe that any given package can only exist in one single copy and
>> this location is not inside the project code space.
>Each package/project should have its own directories. This ensures  
>that a package does not depend on a project, so it can work with many  

Not if they evolve and we must maintain old code when we need to
return to an older time...

>> So if we want to return later to a version that was tagged in order to
>> solve a bug we cannot get everything back to that state because we
>> will still use newer packages than those active at the time the bug
>> was created. Not good at all...
>I can't follow here.
>Use your cvs. Update to the tagged version. Then just press F9 in  
>Lazarus. The IDE will automatically recompile the packages.

Yes, and this then is changed also for other projects that should not
use this version....
>> By having an environment variable one could in principle set that to
>> point to a new place when starting work on a particular project and
>> reset it afterwards....
>Do you mean, you have the same package in several versions on your disk?
>Then why not use cvs to switch between them?
>Why does the package has no version number to distinguish?
I do not use Lazarus except for testing right now. We use Delphi for
our mainline work.
But if we were to switch to Lazarus/FPC then I need to ensure that our
process can still work.
In Delphi there is nothing taht corresponds to packages, the closest I
can get are componentsand even though these have some form ov version
umbers that is not recognized by Delphi so there is no such mechanism
as you propose.

The components I refer to as the Delphi variant to Lazarus packages
are unfortunately code that we have to live with and they evolve over
time. They are also installed in the IDE.
But if we are to return to an earlier point in time it is not enough
to update the project sources to an old tag unless also the components
are updated at the same time to that same time instant.
Hence the need to have them in a controlled environment with the other
project sources outside the IDE. To do that we have gone through a lot
of hoops including project specific search paths.

And we usually are working on several projects at the same time so we
do not want one obstruct the other.

This is exactly why I get worried about the packages being totally IDE
global no matter where they are stored.
Maybe we should not use packages at all, that would at least solve
this problem.


Bo Berglund
Developer in Sweden

More information about the Lazarus mailing list