twe 3 Posted March 18 (edited) When I try to install AsyncPro 2024.02, VirtualTree 2024.02, or SynEdit 2024.02 via GetIt, the process somehow manages to corrupt the DPK files. It changes "requires" to "rrequires", "contains" to "ocontains", and "end." to "d." All the .dpk and project files also have Unix LF line endings. I get this in the Messages window: Quote SynEditDR.dpk(1): Line endings were inconsistent and have been converted to CRLF. SynEditDD.dpk(1): Line endings are LF, but RAD Studio requires CRLF. Consider converting or check your source control settings. Maybe Delphi trying to read Unix text files it doesn't support is what leads to the file corruption. What's going on and how do I make GetIt work for these packages? Edited March 18 by twe Share this post Link to post
Lajos Juhász 270 Posted March 18 I get this all the time. I was unable to figure out the rule when the IDE does this. Share this post Link to post
dummzeuch 1456 Posted March 18 I have seen that happen even without using GetIt. I think it is related to converting the files from LF to CR/LF style line ends. But I never actualy verified this, so I might be wrong. Share this post Link to post
twe 3 Posted March 18 (edited) Given that the problem may well be as simple as the compiler will corrupt .DPKs which have LF line endings, why are the GetIt servers not detecting this issue in packages in the first place? Broken packages shouldn't be offered for download. Does GetIt do no validation and reporting on broken packages on the server side? For this particular problem, GetIt could even automatically fix the .DPKs both on the server side and on the client side. Edited March 18 by twe Share this post Link to post
twe 3 Posted March 19 This problem with .DPKs appears to have existed since at least 2005: http://www.delphigroups.info/2/9/691424.html Share this post Link to post
Brandon Staggs 231 Posted March 19 Somewhat common issue for me, and I don't use GetIt. I have never figured out what causes the IDE to start puking all over the file like that. Share this post Link to post
twe 3 Posted March 20 This is definitely because the .dpk has LF line endings. Steps to reproduce manually: 1. Open SynEditDR.dpk in Notepad++. Make sure "rrequires", "ocontains", and "d." are all fixed and correct. 2. Turn on View -> Show Symbol -> Show End of Line so you can see the end of line characters. 3. Convert SynEditDR.dpk to Unix line endings in Notepad++ with Edit -> EOL Conversion -> Unix (LF) and save 4. Open SynEditDR.dpk in Delphi 12 5. In the project manager, right click on SynEditDR290.bpl and select Options... 6. In the Project Options window make no changes and click the Save button 7. Click Save All on the toolbar or use File -> Save All.. 8. Now go back to Notepad++. It will have detected that the .dpk has changed. Reload the file and you'll see that it's now corrupted with a mix of LF and CRLF line endings, and the usual "rrequires", "ocontains", and "d." problem. If you do exactly the same thing but start by making sure the .dpk has CRLF line endings then there is no corruption of the file. 2 1 Share this post Link to post
Brandon Staggs 231 Posted March 20 Why does the Delphi IDE still not handle line endings properly? Just wondering. 1 Share this post Link to post
Uwe Raabe 1979 Posted March 20 Seems to be a known issue: https://quality.embarcadero.com/browse/RSP-23505 Assuming that the Tools - Editor - Line Endings setting is still set as default, the question is: Why doesn't the IDE fix these wrong line endings to CRLF on loading? Share this post Link to post
Vandrovnik 204 Posted March 20 53 minutes ago, Uwe Raabe said: Seems to be a known issue: https://quality.embarcadero.com/browse/RSP-23505 Reported 5 years ago 😞 1 Share this post Link to post