Recent

Author Topic: .lpi format breaking change  (Read 2257 times)

MarkMLl

  • Hero Member
  • *****
  • Posts: 6676
.lpi format breaking change
« on: August 06, 2020, 04:44:01 pm »
For test purposes I've just copied a project which is regularly compiled using Lazarus v2 back to a machine which only has v1.6.4 on it.

There's been breaking changes in the .lpi file format, and the older IDE ignores it with no error messages- not even anything useful to the console if started from Bash. In order to work around the problem I had to tell the older IDE to recreate the project from the .lpr file, which meant transcribing project settings manually.

FFS chaps, I know that it's virtually impossible to plan ahead to accommodate bright ideas that somebody might have in the future, but PLEASE COULD WE HAVE AN ERROR MESSAGE if a version x parser finds itself trying to read a version x+1 file?

Or even better, could we have a warning when a v1 file is about to be overwritten with an incompatible v2 format? This is EXACTLY the sort of thing that various closed source word processors etc. have been criticised for in the past, and fixing it isn't rocket science.

MarkMLl
MT+86 & Turbo Pascal v1 on CCP/M-86, multitasking with LAN & graphics in 128Kb.
Pet hate: people who boast about the size and sophistication of their computer.
GitHub repositories: https://github.com/MarkMLl?tab=repositories

TRon

  • Hero Member
  • *****
  • Posts: 2435
Re: .lpi format breaking change
« Reply #1 on: August 06, 2020, 04:51:08 pm »
Hi MarkMLI,

I never can remember where it is exactly but 2.x has an option somewhere that you can tell to let it write a backwards compatible lpi file. No idea till how far back it supports though.

Have you tried that already ?
« Last Edit: August 06, 2020, 04:53:25 pm by TRon »

MarkMLl

  • Hero Member
  • *****
  • Posts: 6676
Re: .lpi format breaking change
« Reply #2 on: August 06, 2020, 05:20:40 pm »
Haven't yet seen the option but will investigate, since I'm about to commit updates on the v2 system

MarkMLl
MT+86 & Turbo Pascal v1 on CCP/M-86, multitasking with LAN & graphics in 128Kb.
Pet hate: people who boast about the size and sophistication of their computer.
GitHub repositories: https://github.com/MarkMLl?tab=repositories

lucamar

  • Hero Member
  • *****
  • Posts: 4219
Re: .lpi format breaking change
« Reply #3 on: August 06, 2020, 05:24:12 pm »
AFAICT there has been no changes (at least not important important ones) between 1.6 and 2.0. In fact I regularly open projects created and maintained in 2.0 with 1.6 (and even 1.4), to check for Win9x targets, without problems (other than the normal ones, that is).

Did you perhaps mean projects done with Lazarus 2.2? That is where an incompatibility is deliberately introduced in the XML structure of LPI/LPS/LPK files, as well as an option to mitigate it.
Turbo Pascal 3 CP/M - Amstrad PCW 8256 (512 KB !!!) :P
Lazarus/FPC 2.0.8/3.0.4 & 2.0.12/3.2.0 - 32/64 bits on:
(K|L|X)Ubuntu 12..18, Windows XP, 7, 10 and various DOSes.

TRon

  • Hero Member
  • *****
  • Posts: 2435
Re: .lpi format breaking change
« Reply #4 on: August 06, 2020, 05:29:55 pm »
Thank you for that lucamar as I was unable to to find that entry myself (probably overlooked by hastening my search)

@MarkMLI:
It might be I replied to quickly as the mechanism in place seems a bit more sophisticated ( I could have sworn there was an option somewhere someday before 2.2). Sorry for that. see https://bugs.freepascal.org/view.php?id=22752 and relationships. So your issue might depend on the versions you are using to swap your project around.
« Last Edit: August 06, 2020, 05:32:47 pm by TRon »

MarkMLl

  • Hero Member
  • *****
  • Posts: 6676
Re: .lpi format breaking change
« Reply #5 on: August 06, 2020, 05:36:29 pm »
AFAICT there has been no changes (at least not important important ones) between 1.6 and 2.0. In fact I regularly open projects created and maintained in 2.0 with 1.6 (and even 1.4), to check for Win9x targets, without problems (other than the normal ones, that is).

Did you perhaps mean projects done with Lazarus 2.2? That is where an incompatibility is deliberately introduced in the XML structure of LPI/LPS/LPK files, as well as an option to mitigate it.

About box reports itself as 2.1.0 r63131, but I'll follow that link in a few moments- thanks.

MarkMLl
MT+86 & Turbo Pascal v1 on CCP/M-86, multitasking with LAN & graphics in 128Kb.
Pet hate: people who boast about the size and sophistication of their computer.
GitHub repositories: https://github.com/MarkMLl?tab=repositories

ASBzone

  • Hero Member
  • *****
  • Posts: 678
  • Automation leads to relaxation...
    • Free Console Utilities for Windows (and a few for Linux) from BrainWaveCC
Re: .lpi format breaking change
« Reply #6 on: August 06, 2020, 06:04:45 pm »
About box reports itself as 2.1.0 r63131, but I'll follow that link in a few moments- thanks.

If you're using Trunk (as you appear to be), then I believe you will be affected by this change.

It's not in the Fixes branch or any earlier branch.
-ASB: https://www.BrainWaveCC.com/

Lazarus v2.2.7-ada7a90186 / FPC v3.2.3-706-gaadb53e72c
(Windows 64-bit install w/Win32 and Linux/Arm cross-compiles via FpcUpDeluxe on both instances)

My Systems: Windows 10/11 Pro x64 (Current)

wp

  • Hero Member
  • *****
  • Posts: 11858
Re: .lpi format breaking change
« Reply #7 on: August 06, 2020, 06:54:55 pm »
When you create a project with Laz trunk (not fixes, not 2.0.10) its xml files are written in the new structure with non-numbered nodes which IIRC was required for better maintanance in version control. When you open this project in a non-trunk version the project appears to be empty and it cannot be compiled - yes, without an error message.

You can fix the issue when you open the project again in Laz trunk, go to "Project Options" > "Miscellaneous" and check the box "Maximize compatibility of project files (LPI and LPS)". When you save the project files are rewritten with the old numbered nodes, and non-trunk Laz versions can read it.

If you are a component writer you will be faced with the same issue regarding packages. But there is also a "Maximize compatibility" checkbox in the package options which must be set in the same way. Please note that until several months ago there was bug in this feature which erased the "Maximize compatibility" checkbox from time to time. Therefore, it is highly recommended to use a more recent trunk version.

If you do not use trunk your own projects will not be affected. Only when you open projects written by other people which use trunk. Since you don't have trunk you're out of luck... Contact the author of this project and ask him to set the compatibility flag.

Of course if somebody wants to be a hero for the Lazarus community he could write a conversion tool which reads the new xml files (lpi, lps, lpi), finds the non-numbered nodes, renames them with numbers (<file1> instead of <file>) and rewrites the files. And to become a super-hero you could write an IDE extension which could be installed into older versions.

lucamar

  • Hero Member
  • *****
  • Posts: 4219
Re: .lpi format breaking change
« Reply #8 on: August 06, 2020, 08:04:20 pm »
About box reports itself as 2.1.0 r63131, but I'll follow that link in a few moments- thanks.

Yeah, that's trunk, which will be 2.2 when it stabilizes enough for a release.
Turbo Pascal 3 CP/M - Amstrad PCW 8256 (512 KB !!!) :P
Lazarus/FPC 2.0.8/3.0.4 & 2.0.12/3.2.0 - 32/64 bits on:
(K|L|X)Ubuntu 12..18, Windows XP, 7, 10 and various DOSes.

MarkMLl

  • Hero Member
  • *****
  • Posts: 6676
Re: .lpi format breaking change
« Reply #9 on: August 06, 2020, 08:36:07 pm »
Thanks everybody: that option is a great help. But I remain critical of the lack of sensible error messages , and the lack of a warning message at the point that compatibility is broken.

MarkMLl
MT+86 & Turbo Pascal v1 on CCP/M-86, multitasking with LAN & graphics in 128Kb.
Pet hate: people who boast about the size and sophistication of their computer.
GitHub repositories: https://github.com/MarkMLl?tab=repositories

balazsszekely

  • Guest
Re: .lpi format breaking change
« Reply #10 on: August 06, 2020, 08:43:02 pm »
@MarkMLI
Quote
But I remain critical of the lack of sensible error messages , and the lack of a warning message at the point that compatibility is broken.
Patches warmly welcomed, as always. :)

MarkMLl

  • Hero Member
  • *****
  • Posts: 6676
Re: .lpi format breaking change
« Reply #11 on: August 06, 2020, 08:47:57 pm »
Goes without saying :-)

I must admit though that I've had very little success working out how the innards of the IDE functions- although a "You're about to change the format" warning should be comparatively easy.

It's obviously unfortunate about the older versions, since these should have had a parsing error warning designed into them 15+ years ago... it's a bit late to retrofit such a thing.

MarkMLl
MT+86 & Turbo Pascal v1 on CCP/M-86, multitasking with LAN & graphics in 128Kb.
Pet hate: people who boast about the size and sophistication of their computer.
GitHub repositories: https://github.com/MarkMLl?tab=repositories

TRon

  • Hero Member
  • *****
  • Posts: 2435
Re: .lpi format breaking change
« Reply #12 on: August 06, 2020, 09:36:36 pm »
When you create a project with Laz trunk (not fixes, not 2.0.10) its xml files are written in the new structure......

You can fix the issue when you open the project again in Laz trunk, go to "Project Options" > "Miscellaneous" and check the box "Maximize compatibility of project files (LPI and LPS)". When you save the project files are rewritten with the old numbered nodes, and non-trunk Laz versions can read it.
Thank you very very much wp for having verified my (in)sanity  :D

 

TinyPortal © 2005-2018