*.lpi XML-Structure - why not better way?

[DimProfi]

If you open *.lpi file with a Texteditor, you would see:

<CONFIG>
- <ProjectOptions>
[...]
- - <Units Count="25">
- - - <Unit0>
- - - - <Filename Value="unit0.pas"/>
- - - - <IsPartOfProject Value="True"/>
- - - - <UnitName Value="unit0"/>
- - - </Unit0>
- - - <Unit1>
- - - - <Filename Value="unit1.pas"/>
- - - - <IsPartOfProject Value="True"/>
- - - - <UnitName Value="unit1"/>
- - - </Unit1>
[...]
- - - <Unit25>
- - - - <Filename Value="unit25.pas"/>
- - - - <IsPartOfProject Value="True"/>
- - - - <UnitName Value="unit25"/>
- - - </Unit25>
[...]


Why not just this way?


<CONFIG>
- <ProjectOptions>
[...]
- - <Units>
- - - <Unit>
- - - - <Filename Value="unit0.pas"/>
- - - - <IsPartOfProject Value="True"/>
- - - - <UnitName Value="unit0"/>
- - - </Unit>
- - - <Unit>
- - - - <Filename Value="unit1.pas"/>
- - - - <IsPartOfProject Value="True"/>
- - - - <UnitName Value="unit1"/>
- - - </Unit>
[...]
- - - <Unit>
- - - - <Filename Value="unit25.pas"/>
- - - - <IsPartOfProject Value="True"/>
- - - - <UnitName Value="unit25"/>
- - - </Unit>
[...]


So it would be much easier to insert new units directly with a Texteditor and easier/smarter to parse XML in Lazarus.


And on the other hand:

[...]
<CompilerOptions>
- <SearchPaths>
- - <OtherUnitFiles Value="L:\packages\fcl-web\src\base\;L:\packages\fcl-base\src\;
- </SearchPaths>
</CompilerOptions>


Would be smarter this way:

<CompilerOptions>
- <SearchPaths>
- - <OtherUnitFiles>
- - - <Path VALUE="L:\packages\fcl-web\src\base\">
- - - <Path VALUE="L:\packages\fcl-base\src\">
- - </OtherUnitFiles>
- </SearchPaths>
</CompilerOptions>


It's not a theoretical question. I need it in a real world, while copying projects and setups

[Leledumbo]

Feel free to provide a patch implementing this, however, backward compatibility must be preserved. Think about people who doesn't have or incapable of installing newest version and how the IDE must save it by default.

[DimProfi]

Feel free to provide a patch implementing this, however, backward compatibility must be preserved. Think about people who doesn't have or incapable of installing newest version and how the IDE must save it by default.

So, I'm interpreting your words, that my patch would make sence

Where can I find an official tutorial for submitting patches to Lazarus? Never done it before. 

[marcov]

laz*_xml are key based. IOW  getvalue ('something/other/then')

if you have multiple the same keys at the something/other/ level, you can't distinguish them.

However my knowledge of those units is 2005ish, maybe some of the restructures after have changed it.

[Leledumbo]

Where can I find an official tutorial for submitting patches to Lazarus?

http://wiki.lazarus.freepascal.org/Creating_A_Patch

[eny]

Feel free to provide a patch implementing this, however, backward compatibility must be preserved

Not really an argument IMMHO.
More than once new Lazarus/FPC versions have broken backwards compatibility at the source code level.
A much bigger and more serious problem than having to create a new config.
The --pcp command line option does a great job mitigating the risk when going to a new Lazarus version.

[Martin_fr]

Feel free to provide a patch implementing this, however, backward compatibility must be preserved

Not really an argument IMMHO.
More than once new Lazarus/FPC versions have broken backwards compatibility at the source code level.
A much bigger and more serious problem than having to create a new config.
The --pcp command line option does a great job mitigating the risk when going to a new Lazarus version.

Usually only where unavoidable. There are a also lot of things, that were added, taking extra work to keep them compatible. Imagine the amount of breaking, if that had not been done. It would be massive.

Also differ between backward and forward compatible.

There are cases where something worked in the old version, but does not in the new. "inc(foo.property)" But while a prominent example, this is not a compatibility breakage. This was never *documented* to work (afaik).  It was a bug. Exploiting a bug, does not entitle to complain when it gets fixed.

Then there are cases, where something, that works in the newer version, does not work in the old. That applies to all new features. TComponentAddedIn1_2 can not work in 1.0, but that is not a compatibility breakage (if you count this, there never was compatibility....).
But, if TComponentSinceVeryLong, stops working in 1.0, once it was saved with 1.2, then that is bad (and that are the cases that count as backward compatibility broken). (Again, if a new property was added, you need to strip it away for the old version. BUT it only is saved, if you changed it to a none default value, so if you do not use it, it does not break anything)
That are not so many cases. Yes there where some. They get documented.

Again those are tried to be kept to a minimum.

Changing the format of the project file, means that people can no longer share it with others (that use an old IDE). So a new IDE *MUST* be able to write the old format too.

And ideally, there is a grace period in which the old format is default.

[DimProfi]

I would say, the best way is to make "Save As" option with a file formats: [ Old version (*.lpi) ] and [2014 version (*.lpi)], so the users can export it as old format, when they need to share or distribute it.

And set the new *.lpi format as default, of course

What do you mean guys? 

[Leledumbo]

Apparently, Martin has explained what I meant. Thanks, dude.

I would say, the best way is to make "Save As" option with a file formats: [ Old version (*.lpi) ] and [2014 version (*.lpi)], so the users can export it as old format, when they need to share or distribute it.

And set the new *.lpi format as default, of course

What do you mean guys?  ::)p

Addition: during grace period, old format should be the default.

[DimProfi]

Okay! 

Gonna check the whole XML-Structure for similar changes of *.lpi before 

[Martin_fr]

There can also be an option (in tools / options) to change the default.

So anyone not liking the old default, can change it.

[taazz]

ermmm NO. Just don't, the number of options is getting bigger by the minute there is no need to add options for file formats as well. Make a decision and stick with it if you must do something about it make sure that the end user can write his/her own format through a plugin if required making it possible to do import plugins as well in the process and close it. Don't add yet an other option that no one will ever use.

[DimProfi]

Same "fun" here too   

-<Debugging>
--<Exceptions Count="6">
---<Item1>
----<Name Value="EAbort"/>
---</Item1>
---<Item2>
----<Name Value="ECodetoolError"/>
---</Item2>
[...]

Better:

-<Debugging>
--<Exceptions>
---<Item>
----<Name Value="EAbort"/>
---</Item>
---<Item>
----<Name Value="ECodetoolError"/>
---</Item>
[...]

Do we need a consortium for a new *.lpi format?

[DimProfi]

Just don't, the number of options is getting bigger by the minute there is no need to add options for file formats as well.

May it should be the fundemental requirement in XML-Structures in Lazarus to avoid this kind of naming Item1, Item2, Item3, ... ? 

[Martin_fr]

Well the question is:
Do you want to look at it, and intend to write a patch?

I will get feedback from the other developers, to see what can be accepted (e.g. how additions to the xml parser should look like).

If you plan to do something, I will get  back on those details. (And maybe if you are on the mail list, discussion can be moved there)