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

[Mattias Gaertner]

On Thu, 25 Nov 2010 12:09:16 +0100
Bo Berglund <bo.berglund at gmail.com> wrote:

>[...]
> >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  
> >projects.
> 
> Not if they evolve and we must maintain old code when we need to
> return to an older time...

I only said "should". You can share directories, but then you have to
be more carefully.


> >> 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....

If you want to compile a project which needs a different cvs revision,
then you must update to that revision. If you want to switch often,
you may want to use a faster vcs like svn or bazaar (git is maybe
even faster for this case, but I heard it does not work well under
windows). 
If you want to switch even more often, then install both package
versions in different directories and use version numbers in the
Lazarus packages. If you can not use version numbers, then you can set
for each project explicitly what package file to use. This is then even
more specific than the Delphi search path.


> >> 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.

True.
The Delphi system does not scale well for cross platform, open source,
multi teams. That's why the Lazarus package system tries to maximize
the use of relative paths, has version numbers and one output
directory for each package.

 
> 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.

?
What is the problem of updating the packages to the needed version?


> 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.

Yes, I know that Delphi and cvs have some limits and people had
to invent all kinds of workarounds.

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

I guess that most paid developers work on several projects.

 
> This is exactly why I get worried about the packages being totally IDE
> global no matter where they are stored.

Again, with other words:
A Lazarus package is identified by its name and version. In a
project each package name can only be used once. If a project uses a
package X of minimum version 2.0 then the IDE will search for the X.lpk
with version greater or equal 2.0. When opening another project that
requires the same package X but with a version less than 2.0 then the
IDE will search for the X.lpk with version less than 2.0.
If for some reason you have two different X.lpk with the same version,
then you can set for the project the full path to the X.lpk, so the IDE
will always use this X.lpk for this project.
BTW, you can even have one X.lpk compiled differently for
each project using a different output directory.

So, the phrase "packages being totally IDE global" is wrong in many
ways.

Maybe you have one project that should be compiled with different
versions of a X.lpk?


> Maybe we should not use packages at all, that would at least solve
> this problem.

I still don't know what your problem is.
Maybe the problem is that you want to stick to your Delphi/cvs
workarounds?


Mattias