[Lazarus] How to tell lazarus the location of a used package?
Bo Berglund
bo.berglund at gmail.com
Fri Nov 26 16:01:45 CET 2010
On Thu, 25 Nov 2010 21:05:48 -0500, waldo kitty
<wkitty42 at windstream.net> wrote:
>On 11/25/2010 06:09, Bo Berglund wrote:
>>>> 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
>>> projects.
>>
>> Not if they evolve and we must maintain old code when we need to
>> return to an older time...
>
>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?
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.
--
Bo Berglund
Developer in Sweden
More information about the Lazarus
mailing list