I have switched to using the SVN version of lazarus. I put it in parallel to the binary distribution lazarus so now I have two of them. After I retrieved lazarus from SVN and also the latest release of fpc I got lazarus to compile with help from this list.

So now I am back to my original project and the strange thing is that when I open the project in the new lazarus and compile I get an error because lazarus cannot find the sdposerial package. It actually opens a dialog box with the text:

"The project requires the package "SdpoSerialLaz (>=0.1.3)". But it was not found. See Project -> Project Inspector."

The Project Inspector was already on screen, but I don't know what to do with it. Never seen it before...

I *have* copied SdpoSerial from the original lazarus components dir into the new lazarus components dir. So what more do I need to do in order to get lazarus find the sdposerial package?

I have intentionally NOT *installed* it in any of the Lazarus versions because it does not give me any visual object. But still if I use the original lazarus it manages to find sdposerial, but not with the SVN version.

In Delphi 7 I used to set serach paths for units in my project options thus ensuring that I have full control over which version of common files were used by my application.
But I cannot find a corrsponding property in the lazarus project options....
There simply seems to be no place to set project specific paths at all. What good is project options if you cannot set the project search paths????

Bo Berglund

Just open the SdpoSerialLaz.lpk once.
The "components" directory has no special meaning to the IDE. The package can be anywhere on your disk.

I have intentionally NOT *installed* it in any of the Lazarus versions because it does not give me any visual object. But still if I use the original lazarus it manages to find sdposerial, but not with the SVN version.

The IDE saves the locations of the lpk files in its config directory.

The project specific search paths are in the compiler options. But the directories of SdpoSerialLaz belong to SdpoSerialLaz, not to your project. Just tell the IDE where the SdpoSerialLaz.lpk is and let Lazarus handle the search paths automatically.

Mattias

Bo Berglund wrote

I have switched to using the SVN version of lazarus. I put it in parallel to the binary distribution lazarus so now I have two of them.

and that means you want for at least one of them use (command line param, use windows shortcut / properties )
--primary-config-path=C:\path\to\conf

as long as they share the config dir, you may get a lot of oddities...

Thanks, this solved the problem. But I would *never ever* have thought that the action of opening a file like this would be "sticky" for the future....
What happens if one opens several different same-name lpk files in different locations just to see what they contain? Will Lazarus then use the last opened one? Seems very unsafe for the project to me....

What is the scope of this saving? For the currently open project or for all future and past projects too?

Extremely strange that just opening the file will "tell" Lazarus where the files are for the forseeable future....

Bo Berglund

Each dependency can be given a minimum and maximum version. So the IDE will automatically open a compatible package when you open a project.
And if that is not sufficient you can even give a specific file name (since 0.9.29). Right click in the project inspector on the dependency.

The IDE. So the scope is all projects and packages opened with this IDE. If you open an IDE with another --primary-config-path you will get another set.

It's pretty flexible and comfortable and was done so because of the bad experiences with Delphi.
For example sharing projects/packages is much easier. You don't need to adapt any search path.
Some people want this system even for units: "Why can't the IDE find a unit? I just opened it!"

Mattias

He already uses pcp, otherwise the SVN IDE would have found the package like the release IDE had.

Regards,
Sven

If I do nothing, will they share or not share the config dir? And where is this config dir located?

They will share by default.

depends on os and os version

vista:
C:\Users\<username>\AppData\Local\lazarus

linux
/home/username/.lazarus

Then I don't understand...
I have done nothing about the config (since i did not know it existed), so my new SVN version of Lazarus (the fixes branch) should read the same data as the normal lazarus, right?
Then the same project opened in both lazarus:es would compile the same way, right?
But the original lazarus does not complain about SdpoSerial, but the SVN version does. How come?
Is there a dependency on which version of FPC is used? The SVN version also uses the latest *released* FPC version, while the original lazarus uses the FPC delivered in the setup for lazarus on Windows.

Did you use the pcp parameter as I've suggested you? If so, then you've two different configuration directories (which is the saver way regarding continued use of the release version - in my opinion).

Regards,
Sven

Spot-on!
I had put the --pcp parameter in the shortcut that starts the lazarus instances. I now have a config dir inside the program main folder for each version.
But I copied the data from the original place into both (I think) first.
Anyway, now I understand what is going on and the package is recognized.

Thanks!

Bo Berglund wrote

Anyway, now I understand what is going on and the package is recognized.

Well, I was a bit premature.
I now looked in the config dirs and located the packagefiles.xml files and had a look inside.
This is what I found:

Original Lazarus config:
<Item7>
<Name Value="SdpoSerialLaz"/>
<Version Minor="1" Release="4"/>
<Filename
Value="C:\Programs\lazarus\components\sdpo\sdposeriallaz.lpk"/> </Item7>

New SVN version from the fixes branch:
<Item6>
<Name Value="SdpoSerialLaz"/>
<Version Minor="1" Release="4"/>
<Filename Value="components\Sdpo\sdposeriallaz.lpk"/> </Item6>

Why is one Lazarus using a relative path and the other an absolute path?

Bo Berglund

0.9.29 uses relative paths for packages in the Lazarus source directory. When a new Lazarus is installed under a different path (e.g. the path contains the Lazarus version) all new packages are used automatically.

Mattias

Makes sense to use relative paths to make the environment portable. But if Lazarus only uses relative paths for packages below the lazarus top folder and not for other packages, it might impact portability and co-operation unless all involved developers put the packages below lazarus.
Is it possible to use an environment variable as the top locator? Like for example:
{$PROJECTPACKAGES}\Mypackage\mypackagelaz.lpk

And on Windows the use of locations below the install dir implies that lazarus itself is installed far away from the protected folder trees (like "Program Files" for instance).
Which is what I always do anyway. :-D

Your config files are not ported. They belong to your machine.

Is it possible to use an environment variable as the top locator? Like for example: {$PROJECTPACKAGES}\Mypackage\mypackagelaz.lpk

That would only make sense if PROJECTPACKAGES would change from time to time.

And on Windows the use of locations below the install dir implies that lazarus itself is installed far away from the protected folder trees (like "Program Files" for instance). Which is what I always do anyway. :-D

Mattias

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.

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.

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

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

Zitat von Bo Berglund :

So far this sounds pretty normal.

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.

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.

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?

Mattias

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

Yes, and this then is changed also for other projects that should not use this version....

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.

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

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.

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.

?
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

Bo Berglund wrote

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

Bo, you could notice the discussion about optimization recently, it was also package-related and today I learned a little bout 9.29 build macros feature.

I think it's one of the thing (at least supposed to be) that makes packages less global. For example, you can have package with a single unit, and the uni lists many other units in its uses section. After that you define a build macro changing the search paths depending on the chosen macro value. This value is listed as a drop-down value in the main project options. Starting this moment the package starts to begin being project dependent. You want two versions ago - you change the macro value and rebuild.

The only problem is that it seems that it does not work exactly like Mattias described, changing the values doesn't change the following build result or at least one perform special actions in order for to work (I'm not yet aware which actions). But I'm sure it can be fixed in the future.

Maxs Vlasov
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20101125/e3ed5a87/attachment-0001.html>

Hi,

from outsiders' perspective : how about storing your entire toolchain and project in a (distributed) version control software ? So you can indeed install your packages globally to IDE and have matching versions of packages (and of IDE and of compiler) at any time to go back to...?
Your colleagues could a) check out required changes b) develop in their own branches c) push-pull commits between themselves and the master branch and always have everything that's required for particular revision to compile and run, d) could update their toolchain version to try newer FPC/Lazarus/packages, but still go back to original running setup. All that for just a check-out and rebuild all (ide, packages, maybe fpc) at the start of day or at need;

(I would imagine people do it so if they use Lazarus from SVN...)

The only thing that wouldn't be kept in (d)vcs, would be the compiler needed to rebuild the tool chain from command line, which I imagine should be the one installed system-wide. (Or it could be kept in another repository, so you can go back in time with this as well)

(I know, it is overkill but IMHO simpler than keeping track of single package(s) ?)

Lukasz

isn't this what a versioning system is supposed to be able to take care of?? simply check out the old version and do what you have to do?

this is what i was thinking of with my recent comment in this thread (re: isn't this what a versioning system is for)...

thank you for stating it much better than i was able to ;)

sometimes, the hard part is the details but many times it is also easier to do things the "hard way" because one has total control over everything instead of something doing part of the "automation" and doing it the wrong/undesired way :P

That is exactly what a verioning system is for...

But it also means that EVERYTHING that is used to create a particular software release must be grabbed from the versioning system and used by the IDE. In principle one test is to check out, then do nothing else than build the application. Next do a binary file compare between the newly built version and the one created at the time of the tag. If they are not binary the same then something has changed in the environment...

One such thing is for example IDE specific stuff that works its way into the compiled binary. An example is what I have been saying about Delphi components that are integrated into the IDE but have changed from the time of the old code generation to now.
If these components are not also grabbed on the same tag as everything else then we have a difference...

In Delphi I solve this by not having global paths to the installed components, instead I add the path to each component that is actually used by the project to the project specific browse path list. And I use relative path specifiers.
Then I also make sure that the CVS module definition includes these component sources so they are checked out into the project hierarchy. Then I can use relative paths and I can tag from the top of the project tree and get the tag set also on the component files at the proper state.

The components I am discussing here are not the TForm and what have you that comes with Delphi, instead I refer to the numerous "components" we unwittingly created a long time ago and are actively using in upwards of a hundred programs. Many of these (all except one) are non-visual and should not have been components in the first place, but they are....

But, anyway I get the picture now and I see that if (when) we switch to Lazarus/FPC we cannot migrate these old programs. So when starting afresh in the new environment we can do whatever it takes to get the projects Lazarus-ified....
No components and probably no packages at the beginning.

Same for FPC specific stuff, used third party libs and tools.

In Delphi I solve this by not having global paths to the installed components, instead I add the path to each component that is actually used by the project to the project specific browse path list. And I use relative path specifiers.

You can do the same in Lazarus. As written three times. All good things are three. So I give up here.

[...]

Mattias

Unless I have misunderstood all suggestions concerning this is to actually modify the IDE (Lazarus) for the specific project while it is being worked on. By modify I mean changing package locations for Lazarus etc.
But then one cannot easily switch between different projects and we tend to have multiple projects going on at the same time including supprt ones (those are the ones back in time). Normally we do some stuff then ask the customer a question, immediately switch to the main task and work there while the customer responds.

But agin, I don't want to prolong this, I think I know enough now and my conclusion is that we will start without using packages to see if we are otherwise comfortable with FPC/Lazarus.

Then you'll have to check out every revision into its own directory, possibly with a different package name (including the revision number).

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

That's the typical use-case for virtual machines.

DoDi