Indy package names

[dummzeuch 1515]

A while ago I blogged about my problems with installing TeeChart pro in Delphi 2007, which failed because it assumed the Indy packages to be the ones originally shipped with Delphi 2007 while I had updated to a much later version from GitHub.

 

The problem was that the Indy packages do not adhere to the standard packages naming convention in Delphi.

I would like to know why that is so: Is there a specific reason why the packages (e.g. for Delphi 2007) are called IndyProtocols110.dpk rather than simply IndyProtocols.dpk and configured the version specific 110 suffix to be added by the IDE? The difference is that the generated .dcp file is called IndyProtocols110.dcp rather than  IndyProtocols.dcp. The .bpl file would still be IndyProtocols110.bpl. This would have the advantage that the entries in the required section would also not be version specific, so less changes were required for updating for a new Delphi version.

Edited September 27, 2020 by dummzeuch

[Remy Lebeau 1421]

12 hours ago, dummzeuch said:

The problem was that the Indy packages do not adhere to the standard packages naming convention in Delphi.

Indy is not the only 3rd party component suite that doesn’t.

Quote

Is there a specific reason why the packages (e.g. for Delphi 2007) are called IndyProtocols110.dpk rather than simply IndyProtocols.dpk and configured the version specific 110 suffix to be added by the IDE?

What you are referring to is the LIBSUFFIX feature. And yes, Indy has not been updated yet to use LIBSUFFIX. That is on the TODO list for Indy 11 (https://github.com/IndySockets/Indy/issues/133), which is planned to include other package improvements, like reorganizing the source folders, simplifying the installation process, etc. The main reason why Indy does not use LIBSUFFIX yet is that I simply don’t have the free time to update all of the existing packages for all of the supported IDE versions, and no way to test such a change is working properly across multiple IDE versions (I’m the only volunteer left writing code for Indy, and I don’t really appreciate your blog calling me sloppy over this issue). But also, because Indy 10 predates when LIBSUFFIX usage became common, and because Indy is bundled with the IDE, so changing the package names will break existing projects.  That is why I’ve been waiting for Indy 11 (or at least for a time when I am able to slip this change in between major IDE releases, when Embarcaderom is open to ship such a breaking change).

 

Edited September 28, 2020 by Remy Lebeau

[dummzeuch 1515]

OK, what it boils down to is this:

• It's a legacy from before Delphi 6 when the LIBSUFFIX feature was introduced. And it took even longer before it was widely used.
• You are the only developer left, as as happened many Delphi open source projects, and there are just too many things that compete about your time.
• Other libraries have ignored this too (I specifically mentioned in my blog post that TeeChart does that too, but of course there is also the jcl and jvcl.)
• It's planned for Indy11.

I hereby apologize for using the word "sloppy" in my blog post. I had just spent several hours trying to figure out what the problem was and was quite a bit frustrated.

 

What I don't understand is this:

7 hours ago, Remy Lebeau said:

and because Indy is bundled with the IDE, so changing the package names will break existing projects.  That is why I’ve been waiting for Indy 11 (or at least for a time when I am able to slip this change in between major IDE releases, when Embarcadero is open to ship such a breaking change).

Why should you care whether Embarcadero "is open" to such a breaking change? They are the ones who profit from your work, not the other way around. On the contrary, I would expect them to provide you with some help here.

(But my guess is that they only want to make the library work with the latest Delphi version and would love to to drop compatibility to older versions. This has happened to other libraries too.)

Edited September 28, 2020 by dummzeuch

[Remy Lebeau 1421]

9 hours ago, dummzeuch said:

OK, what it boils down to is this:

All true.

9 hours ago, dummzeuch said:

I hereby apologize for using the word "sloppy" in my blog post. I had just spent several hours trying to figure out what the problem was and was quite a bit frustrated.

Understood.

9 hours ago, dummzeuch said:

Why should you care whether Embarcadero "is open" to such a breaking change?

Because they bundle Indy pre-installed in every IDE release, and most users are more comfortable using the pre-installed version than going to SVN/GitHub to manually install a newer version.  And because Embarcadero uses a private copy of Indy for their internal technologies that is not always separated properly from the public version, and so can cause conflicts with user-installed versions of Indy.  And because Embarcadero does not update their shipped/private copies of Indy on every IDE release (although they did for 10.4).  So making breaking interface changes (which I sometimes do, but I try to keep it minimal) in the public version of Indy is not always possible/feasible, without causing more trouble than it solves.

 

That being said, my ultimate goal (which I have no ETA on) is to 1) get Indy 11 finished and released; 2) get Indy into GetIt; 3) maybe not have Embarcadero ship Indy with the IDE anymore, in favor of GetIt (if it works out).

9 hours ago, dummzeuch said:

On the contrary, I would expect them to provide you with some help here.

Once in awhile, Embarcadero contribute bug fixes (and occasionally ships breakages without me having reviewed their changes first).  That is about it.

9 hours ago, dummzeuch said:

But my guess is that they only want to make the library work with the latest Delphi version and would love to to drop compatibility to older versions.

Yes, of course Embarcadero, being the IDE/compiler vendor, doesn't have to care about their bundled 3rd party packages being backwards compatible, but of course Indy, as the 3rd party code, has to worry about that.

 

Which sucks doubly so for me personally, because several times in the past few years, I have suffered total system losses (mostly due to hardware failures) that have lost me my main dev machine and backups, so most of my personal projects are gone, as well as most of my RADStudio VMs (and the ones that are left are expired betas).  I borrowed a family member's laptop to carry on, but have no dev tools installed on it,  So while I can make edits to source code in Notepad, I can't compile anything.  And, to be quite frank, I just don't have the time or energy to try to setup a new dev environment right now.  So, I do what I can with what I have to work with, but I know it is not good enough long term.

[dummzeuch 1515]

14 hours ago, Remy Lebeau said:

several times in the past few years, I have suffered total system losses (mostly due to hardware failures) that have lost me my main dev machine and backups, so most of my personal projects are gone, as well as most of my RADStudio VMs

Ouch, that sucks. Of course, now telling you you should have made backups doesn't really help. 😉 On the other hand, I have only recently started to make frequent backups of my private computer, which does not include the Delphi installations though, just the ISOs, my personal documents and photos and the source code that isn't in public repositories anyway. So It could happen to me too and I don't know whether I will bother to install many of the old Delphi versions I currently have.

 

Speaking about having no compiler(s): I would be able and willing to do compile tests for Delphi 5 to 10.4 for Indy if you want. But that would need some working compile batch files (the current ones for at least Delphi 2007 are broken).

[Gary Mugford 12]

I recommend using Amazon Glacier to do your backups. I watch my pennies and storing my backups in Glacier is the coldest of cold backups. If something goes south (again ... yeah, again), then I can get my files out of storage and have my HW guy put them on the new machine. It's not a quick process, but my HW guy doesn't always have the time to jump to my aid immediately. So I don't mind the slowest recovery of my stuff in return for the cheapest price. Since we are talking about disaster, having something immediately at hand (less than six hours) isn't worth the king's ransom that Amazon demands.

 

My daily routine on my production machine is to have all of my boot drive, data drive and apps drive disk imaged to another drive (external) to the system. I keep a month's worth of nightly backups. The data drive is backed up over my home network to my impending production machine and to an old Windows XP machine I keep around to test my sales register software because half the stores are still using XP. If it works, why fix it??? Thus I have XP, 7 and 10 copes of my data that are simple single copies. Once a week on the weekend, I have the Glacier software prepare a new update to Glacier and upload it while I watch whatever sports are on the TV. And with all that, I still use and ABSOLUTELY NEED, AJC's Active Backup for versioning. The AJC data is on the data drive and thus gets it's share of backups.

 

I have a small sliver of a percentage of the software the respondents of this thread have in terms of personal production. I would think you folks have much more to lose than a guy like me with a few clients and the projects they require me upkeep and add to. I DO have more than 40 years in the programming game though. And I could not bear to part with it permanently.

[Remy Lebeau 1421]

8 hours ago, dummzeuch said:

Ouch, that sucks. Of course, now telling you you should have made backups doesn't really help. 😉

Actually, I did have a backup at the time (a RAID1 NAS), but a bad firmware upgrade of the NAS server corrupted both HDD's filesystem, rendering them both unmountable.  And I haven't had the time or money to get them recovered professionally yet.  Now I have a new non-RAID NAS for my current backup, but it doesn't have any of my old files on it, only the files that were on my laptop at the time, and that wasn't everything that was in the original backup.  And then that laptop died unexpectedly awhile back ago, so now I'm on a new laptop, and it has only my recent documents and latest Indy code on it, that is about it.  No compiler, no IDE, no VMs.

Quote

Speaking about having no compiler(s): I would be able and willing to do compile tests for Delphi 5 to 10.4 for Indy if you want.

Any help is appreciated.

Quote

But that would need some working compile batch files (the current ones for at least Delphi 2007 are broken).

In what way?  Although, *Delphi* installations really should not be using the batch scripts at all, compiling and installing directly from within the IDE is preferred.  It is *C++Builder* installations that still need the batch scripts.

Edited September 29, 2020 by Remy Lebeau

[dummzeuch 1515]

14 hours ago, Remy Lebeau said:

(about the batch files)

In what way?  Although, *Delphi* installations really should not be using the batch scripts at all, compiling and installing directly from within the IDE is preferred.  It is *C++Builder* installations that still need the batch scripts.

Because I don't want to start all the IDEs to do a compile check (double click, wait, click, click, CLICK ...). I'd rather start a batch file that calls them all, one after another. I'll do a checkout and have a look what needs to be done.

[Lars Fosdal 1793]

@dummzeuch Have you tried the free Solo version of Continua CI?  It is full featured but limited to one task at a time. Beats batch files by a mile.

[dummzeuch 1515]

29 minutes ago, Lars Fosdal said:

@dummzeuch Have you tried the free Solo version of Continua CI?  It is full featured but limited to one task at a time. Beats batch files by a mile.

No, I haven't. Didn't know there is a free version and I already have a batch solution for all my projects which has the advantage of not needing any additional software. And of course that also needs yet another tool to learn. I guess you use Continua CI at work, so you know how to use it.

 

I'll keep that in mind though, it might be worth spending the time (and possibly money).

[Lars Fosdal 1793]

We do use it at work.  It is pretty uncomplicated to use, but yeah, a lot of features and settings to be explored to master it fully.

[dummzeuch 1515]

@Remy Lebeau is there any reason to not use msbuild for Delphi 2007 and later? I'd hate to spend time on figuring out dcc32 parameters only to be told "Why didn't you simply use msbuild?".

[Remy Lebeau 1421]

7 hours ago, dummzeuch said:

@Remy Lebeau is there any reason to not use msbuild for Delphi 2007 and later?

Indy stopped using batch scripts altogether for Delphi installations after D2009, in favor of IDE-based installations.  Indy does use MSBuild for C++Builder XE2+ installations.

 

I didn't write the old DCC32-based batch scripts, or the updated MSBuild-based scripts.  MSBuild was first introduced in D2007, but it likely wasn't until XE2 that use of it caught on.  Or maybe XE2 was just the oldest version that Malcolm Smith (who wrote the MSBuild-based scripts) could support at the time.  I don't know.  I just maintain them.

 

I'm not against migrating the 2007-XE batch scripts to MSBuild, but I have no way to validate/test them myself.  But the ultimate goal is to move Indy away from using the batch scripts at all, for either Delphi or C++.  The installation needs to be more streamlined (my goal for Indy 11) so that Indy can eventually be migrated to GetIt.

 

Edited September 30, 2020 by Remy Lebeau

[dummzeuch 1515]

 

51 minutes ago, Remy Lebeau said:

The installation needs to be more streamlined (my goal for Indy 11) so that Indy can eventually be migrated to GetIt.

What do you mean by "more streamlined"? Does getit provide a mechanism to compile and install packages? As far as I know it doesn't.

[Remy Lebeau 1421]

2 hours ago, dummzeuch said:

What do you mean by "more streamlined"?

My goals for Indy 11 include adding use of LIBSUFFIX on the packages, changing the structure of the source folders, and reducing the steps needed to compile and install the packages.

2 hours ago, dummzeuch said:

Does getit provide a mechanism to compile and install packages? As far as I know it doesn't.

A few years ago, Embarcadero sent me a document listing the available commands that GetIt had implemented at the time (I'm assuming the same set of commands still applies today).  There are CompileProject and InstallPackage commands listed in that document.

[dummzeuch 1515]

As it stands, I'm not a big fan of Getit. From the few packages i have tried to install, several didn't install currently. And don't get me started about the 10.4.0 patches...

 

Anyway: Did you have a chance to look at the pull requests? Is it OK with you to continue in that direction for the time being (for Indy10). Working compile scripts make it simpler to compile the packages, that's all I want to achieve for now.

 

I've got some ideas to improve them further, but before I invest the time, I'd like to get your approval.

[Remy Lebeau 1421]

9 hours ago, dummzeuch said:

Anyway: Did you have a chance to look at the pull requests?

Not yet.

9 hours ago, dummzeuch said:

Is it OK with you to continue in that direction for the time being (for Indy10). Working compile scripts make it simpler to compile the packages, that's all I want to achieve for now.

Updating the existing scripts to make sure they work properly is one thing.  Adding new scripts for new IDEs is another, it is just one more headache to maintain.  But if you want to provide some scripts, I'll look at them.