Recent

Author Topic: Recovery a lazarus project folder from a backup had issues  (Read 6258 times)

picstart

  • Full Member
  • ***
  • Posts: 236
Recovery a lazarus project folder from a backup had issues
« on: June 05, 2011, 04:59:54 am »
I am concerned about lazarus dependencies. I have a lazarus projects in separate folders. I assumed that I could rename a unit outside of the lazarus IDE and change references to it in the uses sections. It has been a nightmare of dependencies. The original name of a unit is recorded and  hidden somewhere outside the visibility of mycode and creates issues with mycode at compile time. The compile seems to point to the ghost unit that no longer exists since it was renamed.
I next assumed I could just get my Acronis backup of the folder containing the project and restore it. This restored some function but since I added function to a component package it has dependencies back to an earlier version.. I am very insecure now with lazarus since I have no certainty that the code I wrote and the form I designed that were placed in the folder I chose is all there is. Obviously a complete restore of my system would work. I dislike the trend where lazarus places functionality all over Ex app data \lazarus to lib folders to backup folders to xml files connected to packages. Sure the IDE has several trees to show dependencies but this metastatic growth of interdependent  files is not actually making things better or easier to backup and restore. 

Leledumbo

  • Hero Member
  • *****
  • Posts: 8114
  • Programming + Glam Metal + Tae Kwon Do = Me
Re: Recovery a lazarus project folder from a backup had issues
« Reply #1 on: June 05, 2011, 09:24:38 am »
Quote
I assumed that I could rename a unit outside of the lazarus IDE and change references to it in the uses sections. It has been a nightmare of dependencies. The original name of a unit is recorded and  hidden somewhere outside the visibility of mycode and creates issues with mycode at compile time. The compile seems to point to the ghost unit that no longer exists since it was renamed.
That's normal, and you shouldn't do that. Your project information (what files, compiler options, etc) is written to .lpi file of your project. The compiler would work if you change manually outside the IDE, but many IDE features regards information from .lpi file.

eny

  • Hero Member
  • *****
  • Posts: 1588
Re: Recovery a lazarus project folder from a backup had issues
« Reply #2 on: June 05, 2011, 10:54:53 am »
I know the feeling. When I first started with Lazarus I had similar issues which in the end all proved to be non-fatal (it takes some time getting used to how the IDE works).

I assumed that I could rename a unit outside of the lazarus IDE and change references to it in the uses sections.
This does work as long as you a) remove the original unit file from the project (see Project/Project Inspector) and b) inside the unit file rename the unit as well. It's easier to load a file into the IDE and do a Save As...
Quote
The compile seems to point to the ghost unit that no longer exists since it was renamed.
This is the compiled unit that you didn't delete. What I sometimes do is delete the complete contents of the lib directory (all compiled units). This forces the IDE to compile all units required for a project. I too use many different (library) folders for my projects.
Quote
Obviously a complete restore of my system would work.
That's rather drastic :)

Quote
I dislike the trend where lazarus places functionality all over Ex app data \lazarus to lib folders to backup folders to xml files connected to packages. Sure the IDE has several trees to show dependencies but this metastatic growth of interdependent  files is not actually making things better or easier to backup and restore. 
The main project folder is where all the action happens (and if you create packages yourself, then in the packages lib folders as well).
All posts based on: Win10 (Win64); Lazarus 1.8.0 'stable' (#56594 win64) unless specified otherwise...

cecarnicom

  • New member
  • *
  • Posts: 9
Re: Recovery a lazarus project folder from a backup had issues
« Reply #3 on: October 07, 2019, 07:08:05 am »
As a new user of Lazarus, I agree rather strongly with the opening post by picstart.  Creating an independent backup version without interdependencies and crossovers seems to be much more of a headache than I would expect.  Introducing compiler errors when attempting to switch between projects and attempted backups also seems to be problematic.

I am still wondering what is the proper and simple way to create a backup of a successful project without disturbing anything in the original version, or the subsequent backup, and to ensure that they will load and close completely independently from one another.

Also the reasoning as to why these difficulties occur would be helpful to understand.

Thanks much for any suggestions as how to proceed simply and cleanly with maintaining the integrity of multiple program projects and creating independent backups along the way.  Best regards, CEC

howardpc

  • Hero Member
  • *****
  • Posts: 3203
Re: Recovery a lazarus project folder from a backup had issues
« Reply #4 on: October 07, 2019, 08:09:36 am »
I am still wondering what is the proper and simple way to create a backup of a successful project without disturbing anything in the original version, or the subsequent backup, and to ensure that they will load and close completely independently from one another.

A good way to back up a project is simply to do Project->Save Project As... in a new clean directory. You can also use Project->Publish Project, which saves the project in a folder you specify (several standard locations are offered, or you can pick a custom folder) and optionally also zips the project.

Quote
Also the reasoning as to why these difficulties occur would be helpful to understand.
A Lazarus project is a complex beast, managed largely behind the scenes by the IDE (this is part of what "Integrated" means in "I"DE). Picking out one or two pieces of project (such as the odd file or two from the default Backup directory) and reinserting them in a live project may well confuse the IDE because it is not automatically managing the changes you make. The IDE manages file names and the state of all project files especially closely -- this is what integration of all the parts of a project partly means. If you don't use IDE-provided mechanisms to make changes to files it can throw a spanner in the works of the behind-the-scenes integration.
For instance, the integration between a form .pas unit and its corresponding .lfm property data file is particularly tight (as it must be). Interfering with an .lfm while the form is open in the IDE can quickly prove disastrous if you don't know what you are doing, and often even if you think you do know what you are doing.

Which is not to say that making changes to a project outside of the IDE cannot be done. But you need a fairly deep understanding of the IDE's management strategies to do this in a way that does not corrupt your project. It is nearly always easier and simpler to use the IDE's own mechanisms to make changes.

wp

  • Hero Member
  • *****
  • Posts: 6485
Re: Recovery a lazarus project folder from a backup had issues
« Reply #5 on: October 07, 2019, 10:22:19 am »
A good way to back up a project is simply to do Project->Save Project As... in a new clean directory.
No. This only writes a new copy of the lpi and lpr files to the new location, but leaves the units and other files in the old directory and adjusts the paths accordingly. As we had discussed recently, this can cause a lot of confusion when the user manually copies the units to the new directory and wonders why they are not used.

Using the "Save as" from the File menu is even more dangerous. If applied to a unit which belongs to a package it modifies the path to the unit in the package. There is a messge "Delete old file?" If you don't know what you are doing and say "Yes" then the file is deleted from the package. Even if this is answered by "No" the new path is written to the package file when you confirm to save the modified package. This change may remain unnoticed for a long time, or suddenly lead to ununderstood behavior when, for example, the new folder is deleted and the package cannot be compiled any more.

I strongly discourage using any of the "Save as" commands of the IDE for backup purposes, they are accompanied by a series of side-actions which have a meaning only within a project. Make backup copies outside the IDE. Use the "Save as" commands only when you know what your are doing.

You can also use Project->Publish Project, which saves the project in a folder you specify (several standard locations are offered, or you can pick a custom folder) and optionally also zips the project.
Yes, that is the only way to copy an entire project including all files from within the IDE. Maybe the menu item is named in a misunderstanding way, "Backup project" appears more appropriate to me.
« Last Edit: October 07, 2019, 10:47:42 am by wp »
Lazarus trunk / fpc 3.0.4 / all 32-bit on Win-10

wp

  • Hero Member
  • *****
  • Posts: 6485
Re: Recovery a lazarus project folder from a backup had issues
« Reply #6 on: October 07, 2019, 11:16:36 am »
I am concerned about lazarus dependencies. I have a lazarus projects in separate folders. I assumed that I could rename a unit outside of the lazarus IDE and change references to it in the uses sections. It has been a nightmare of dependencies.
In a "normal" project all units are relative to the project folder, there is no need to change references to units at all. Or do you add libraries by extending the search paths of a project? Don't do this, add the related package to the requirements of the project and let the IDE do the job of finding the units.
Lazarus trunk / fpc 3.0.4 / all 32-bit on Win-10

cecarnicom

  • New member
  • *
  • Posts: 9
Re: Recovery a lazarus project folder from a backup had issues
« Reply #7 on: October 08, 2019, 09:58:53 am »
I appreciate these comments; the discussion thread confirms to me that this is not just a trivial issue within Lazarus.  Out of necessity after experiencing numerous complications during the early learning curve on the IDE, I have come up with a method of protecting the work and keeping each project and version separate and free from errors.  It may certainly be convoluted to the members, as it is to me, but at least it is working for me. My general steps/methods are now:

1. I work with the project mode now, to create, work, and save.
2. I make sure that the "working directory for test files" is now set BEFOREHAND within options to the actual directory the project will reside in.  Only then do I actually load up the project and compile and save, and then I do not have any problems with crossovers anymore.  The only real catch is that Lazarus does not allow me to do this separately beforehand before loading the project (so far here..) so I work with a dummy example project to allow me to get into the options window first.  After it is set properly, then and only then do I load my project.  I know this has to be peculiar, but so be it for now since it at least works and I no longer have the numerous headaches from first uses of Lazarus.
3. I am having no problems any more of this nature, each project is separate, and compilation is finally contained within one place where I know what it is.
4. I suspect there will be comments to improve this process, but I needed something to work after all the initial problems I was having.  I do think Lazarus could benefit from cleaning up the backup procedure; not unreasonable to anticipate a button that says backup, and get clean results along the way.

Thanks for comments, at least the work has become peaceful, fun and constructive again, but not so when the first level of chaos erupted with the program structure being torn asunder because of ignorance here.

Best regards, CEC

PS: HowardPC, a special thanks for your comments and suggestions; they are very much in accord with what I have decided to do here and it seems to work fine.  CEC
« Last Edit: October 09, 2019, 08:55:18 am by cecarnicom »